Panel

• Igor Minar (twitter github blog)
• AJ O’Neal (twitter github blog youtube)
• Sean Hess (twitter github blog)
• Jamison Dance (twitter github blog)

Discussion

01:36 - Igor Minar Introduction

• Teamleader on AngularJS
• Google 02:24 - Igor’s History with Angular 06:37 - The Growth & Innovation of Angular
• Dart
• AngularDart 14:07 - Minification & The Closure Compiler18:36 - Dependency Injection & Annotation 22:03 - Using TypeScript with Angular 26:08 - Error Messages
• diary.js 29:25 - Angular & Google 33:30 - Error Messages (Cont’d) 34:53 - Contributing to Angular and Open Source Projects
• [Google Group] angular-dev

Picks

• Google (AJ)
• Introducing Coffee-to-the-Home (AJ)
• geppetto (Jamison)
• Worm (Sean)
• Pact (Sean)
• Blindspot: Hidden Biases of Good People (Igor)

Next Week

Dependency Injection in JavaScript with Vojta Jína & Misko Hevery

Transcript

AJ:  This is the problem, Jamison. We definitely need more than just me and you because, well maybe you can carry it mostly on your own but I’m not important enough. [This episode is sponsored by Frontend Masters. They have a terrific lineup of live courses you can attend either online or in person. Their upcoming course is Hardcore Functional Programming in JavaScript with Brian Lonsdorf. You can also get recordings of their previous courses like JavaScript the Good Parts, AngularJS, CSS3 In-Depth, and Responsive Web Design. Get it all at FrontEndMasters.com.] [This episode is sponsored by WatchMeCode. Have you been looking for regular high-quality video screencasts on building JavaScript done by someone who really understands JavaScript? Derick Bailey’s videos cover many of the topics we talk about on JavaScript Jabber and are up on the latest tools and tricks you need to write JavaScript. He also covers language fundamentals, so there’s plenty for everybody. Looking over the catalogue, I got really excited and I can’t wait to watch them all. Go check them out at JavaScriptJabber.com/WatchMeCode.] [This episode is sponsored by Component One, makers of Wijmo. If you need stunning UI elements or awesome graphs and charts, then go to Wijmo.com and check them out.] JAMISON:  Hello everyone. Welcome to episode 108 of the JavaScript Jabber Podcast. I am the guest host pinch hitting for Chuck. I’m Jamison Dance. And we have AJ O’Neal with us. AJ:  Yo, yo, yo, coming at you live from a desk that I can put my legs under. JAMISON:  We have Sean Hess coming to join us today. SEAN:  Hi everybody. JAMISON:  And we have a special guest, Igor Minar. IGOR:  Hi everybody. JAMISON:  So Igor, tell us all about yourself. Who are you? IGOR:  [Chuckles] JAMISON:  What do you do? IGOR:  How far back do I need to go? JAMISON:  [Chuckles] IGOR:  Do you want a history or what I do right now? JAMISON:  Any of it. IGOR:  So, right now I’m the team leader on the AngularJS project. I’ve been working on Angular for four years now and it’s crazy. It just keeps on changing every year. JAMISON:  [Chuckles] IGOR:  And it’s amazing. I work at Google. And previously I worked at Sun Microsystems. I did stuff with Java and later Ruby, JRuby, Rails. And about four years ago I moved to JavaScript. AJ:  So, you moved to JavaScript to work on Angular, is that what you’re saying? Four years ago, you started both? IGOR:  Yes. I did some JavaScript before but not full-time. Pretty much when I joined Google to work on Angular, I started doing JavaScript full-time. JAMISON:  Were you involved in the creation of Angular or did you join it once it already existed? I don’t actually know the whole history. I know at one point, Google purchased a company that was working on Angular and that’s about it. Is that correct? [Laughter] IGOR:  No, not at all. JAMISON:  Oh, man. Okay. [Laughter] IGOR:  It’s funny. JAMISON:  You didn’t have to fight a bear and then rescue a princess and in the treasure chest you found Angular? That was the story I heard. IGOR:  You forgot about the dragon, though. JAMISON:  Oh, yeah. IGOR:  [Chuckles] So, I came onboard when Angular was just open sourced. I think that happened a couple of months before. And there were pretty much only Miško. And maybe one or two people were helping with Angular, but Miško was the only person working fulltime. There was another person involved. Adam was helping Miško before Angular was open source. So, originally Angular was meant to be something completely different. It was meant to be a way of building applications, web applications, for designers. It had a backend story with it, like automatic syncing. And it had all the data binding and all the declarative nature that we’re familiar with today. But it wasn’t really meant for web application developers. It was meant for web designers to build more simple applications but still in very declarative ways, in a way that was familiar to web designers. However, Miško was working on a different project at Google. So, this was happening as a side project for Miško. It wasn’t a project happening on Google. But at the same time, Miško was working on a different project at Google, which was a web application. And they were not making a whole lot progress even though they were trying hard to build this relatively complex application. And they were very frustrated by the current state of technologies. And that’s when Miško got this idea that, “Hey I have this toy thing here that I’m building for designers. If we changed it and if we exposed hooks for web developers, then we can actually build very powerful web applications with this technology, but in a much more simple way,” and in a way that is more declarative and more testable and has all these other benefits that people love about Angular today. SEAN:  Who was using Angular at the time, Igor? IGOR:  Before Google got involved or after Google got involved? SEAN:  I guess right after is what I’m curious about. IGOR:  So, before Google got involved there were just a few people, nothing significant. It was pretty much early beta or alpha, depending on how you look at it. When Google got involved, it was primarily Google using it. So, Google was using it for internal application. It was an administrative interface for Google Feedback. I don’t know how many of you are familiar. But whenever you want to post a bug or some feedback about a Google product, you interact with this tool that takes a screenshot of your state and allows you to send a description of what’s wrong or what could be improved. And what Miško and the team at the time were building was an application that will allow this feedback to be processed and displayed and acted on. So, it was this internal rather complex application. JAMISON:  Cool. So, you said that you’ve been working on it for four years and every year the job you do changes dramatically. Can you expound on that a little bit? How has it changed in the years you’ve been working on it? IGOR:  Well, so I said the number changed every year. JAMISON:  Oh. IGOR:  But you’re actually right. The job changes every year, too because Angular matured and evolved. Things changed rapidly. Four years ago when we started, we didn’t really have anybody to support. There was no community. We didn’t do any kind of presentations or we didn’t worry about documentation at that point, because there were so few people working with Angular that it was easy to just talk to them. And even if we had few documents and if something was unclear, they could just talk to us and we could explain things. So, at that time, things were rather chaotic but also much simpler. Many of these things that we have today we didn’t have at the time and we didn’t have to worry about it. So, today Angular’s much more mature. There’s a ton of people using it, depending on it. So, things are much more serious. And the way you approach a project at such stage is also different. So, that’s how my job changed. JAMISON:  So, while you were talking I was just thinking about some of the parallels between the growth you described and the growth of a company and how you just scale communication among people. IGOR:  I can imagine that it’s very similar with a company. Yeah, you can think of any successful open source project to be like a booming startup that is getting headcount growth and there are more people involved that you need to work with. You can get more done but there is also communication overhead and things that you need to deal with. JAMISON:  Yeah, exactly. At the beginning where five people are using it, you just all are in the same chatroom. IGOR:  Yeah. JAMISON:  And you can have 100% of the information shared that way. IGOR:  Yeah. JAMISON:  But it doesn’t scale like that. IGOR:  Yeah, you have ten customers and it’s easy to just make a phone call. JAMISON:  Yeah. [Chuckles] IGOR:  [Inaudible] with them and just, “How do you like our product?” and they can tell you directly. And then you can go and make the changes. And most of the time you will not make the other nine people angry. But when you have 10,000 people or 10 million people using your product then you have to approach changes differently. SEAN:  Do you think it’s… JAMISON:  So, how… Go ahead, Sean. SEAN:  Do you think it’s harder to innovate and move Angular forward now that you have such a wide user base? Or is it still moving forward quickly? IGOR:  It’s definitely more complex. And the innovation happens in different ways. So, before we could innovate directly in Angular. Whenever we saw some problem, we brainstormed and came up with some solution and then implemented directly. Before 1.0 any breaking changes were easy to make. You would just document them and people would just move on and they would be like, “Yeah, this is not stable.” But once you declare 1.0 and you say this is production ready then your ability to innovate is constrained by how much you can change without making breaking changes to the application, how much you can change without changing some of the main principles in the framework. Because it’s really hard to re-train people, so you don’t want to make fundamental changes to the framework that people are using and relying on. JAMISON:  You can’t move their [inaudible] too much. IGOR:  [Chuckles] Yeah. So, the way we deal with this is there is still a lot of space for improvements and innovation in terms of, just look at the animation feature that we added in 1.2. That was completely new. And it was an addition, something that we could just add to Angular. It was a complementary feature. Whereas we know that there are some issues in the core of the framework but changing them would break pretty much everybody that uses Angular. So, we can’t do it just without any kind of preparation or any kind of roadmap or announcements. So, while we do want to fix these issues that we identify, they’re going to take longer to trickle into something that people can use. JAMISON:  That’s some really interesting insight. IGOR:  Yeah. So, one advantage we had was that last year we implemented Angular in the Dart language. And that was very interesting because Dart at the time was unstable. And we were asked to create a port of Angular that you could use with the Dart language. I don’t know how many of the listeners are familiar with the Dart language. But there are some differences between JavaScript and Dart that make it very hard to build a framework in JavaScript and then use it in Dart. So, if you want to provide a good experience to developers, you need to build a framework in Dart. And there was a demand, internally at Google to have such a framework. So, that’s why we built it. And one thing that this enabled us was to start from scratch and fix some of the issues that we saw in AngularJS and experiment with new solutions. Because often when you see a problem it doesn’t necessarily mean that you know how to fix it. You might have some ideas that this other way of doing things might be better. But my experience tells me that every solution has some tradeoffs. And often these tradeoffs are unknown until you actually implement the solution and try it with some applications. So, one thing that we were able to do with AngularDart was start from scratch, build the framework again in a different language but the core principles remain the same, and experiment with different  ways of fixing the issues that we know exist in AngularJS but we can’t fix them incrementally. So, as AngularDart is getting more mature, we’re getting this knowledge. And then when we see ideas that we can bring back to AngularJS without any kind of breaking changes or in a way that is compatible with AngularJS, we’re already doing that. And there are several examples of that happening over the past few months. And one of the bigger changes that we want to make have been tested in AngularDart to see that yes, it makes sense to solve this particular issue that we have with AngularJS in this particular way. And the tradeoffs are better than the tradeoffs we are making today in AngularJS. JAMISON:  That’s really interesting. I’ve never thought about the role of AngularDart as a way to prototype your ideas or check the validity of some new architecture things. That’s cool. IGOR:  Yeah, and to do these big changes in a way where you don’t confuse people. Because as a framework author we often need to see that the changes that we’ll be making or the features we’re implementing actually makes sense in practice. And to do that, you need a real application and a real application development team to work with. This is one thing that AngularDart enabled us and gave us. So, I think it’s very good for AngularJS. And many people don’t see this. I get questioned so many times about AngularDart and why are we dropping JS. JAMISON:  Yeah, you take lots of flak for it, kind of. IGOR:  Yeah. “Why don’t we like JavaScript anymore?” or whatnot. And that’s not the case at all, no. AngularDart exists because Google has a need for AngularDart internally. And so, we’re building primarily for internal use in Google. But it’s open source. Anybody external can use it. And the benefit that we get for AngularJS is that it’s this greenfield project where we can learn about other approaches to some problems we see in AngularJS and validate them and then bring them back to AngularJS. JAMISON:  That’s really cool. That’s the freedom that success buys you too, right? I would doubt that most open source projects have the popularity and the support from someone like Google to just be able to rewrite everything from scratch on a new platform. IGOR:  Well, it’s a lot of work. [Chuckles] JAMISON:  Yeah, yeah, yeah. IGOR:  Don’t think that it’s like, just, “Oh, [inaudible].” JAMISON:  Yeah. Right. You probably just have a bash script that replaces [inaudible]. [Laughter] JAMISON:  And you sit back and drink lemonade. IGOR:  I wish Google Translate can just translate it. [Laughter] IGOR:  JS to Dart or the other way around. AJ:  Is there somebody on the team working on that? [Laughter] IGOR:  Well actually, Dart has a pretty good transpilation story to JS. So, there is a story for writing code in Dart and then just using it in JS without any knowledge of Dart. And there’s also a story the other way around. You use JavaScript from Dart. It’s just all these solutions are not suitable for framework-y code. You could write a component or a utility library that you just make one call into and it does a lot of stuff and then returns the response. But with a framework, you have code that there’s a lot of context switches between the code that you wrote to the application in the framework. This goes back and forth. And any kind of translation boundary between these two codes is undesirable because of IPI friction and performance issues and that kind of stuff. JAMISON:  Sure. AJ:  So, I want to bring up something else. And maybe this is off topic so we can just ignore it and come back to it later. But I think that Angular in of itself is kind of another language in that you are introspecting the language and then you’re mangling it, primarily just the dependency injection. I’m not sure where else it might be done. But I recently found out why some of my code wouldn’t minify correctly. And it’s because I’m using ui-router instead of ng router, because ui-router seems to be a more robust solution. But the ng minifier it seems can’t minify. It’s not aware of ui-router. So, you have these two Angular components but the one isn’t really aware of how it should minify the other. Do you get what I’m saying? IGOR:  I’m not sure. I’m not familiar with this particular use case. But we do know that the way DI works and the way we gather tokens as we’d call them, identifiers for services that need to be injected into various methods, we made one mistake in this case where we optimized for the case where you don’t minify the code and made the string annotations that we can use for DI, our string tokens an opt-in. And that proves to be problematic for bigger applications of production code. And it’s one thing. This is like an artifact of trying to build a solution that works for both Google and non-Google applications. I don’t know how much you guys know about how software is developed at Google. But everybody who’s familiar would agree that it’s very different from how software is built outside. JAMISON:  Can you elaborate on that a little bit? IGOR:  At Google, a lot of the code in JavaScript is statically analyzed using the Closure Compiler. And almost all JavaScript code is annotated using type annotations that come from the closure extension to JavaScript. I don’t know how to correctly describe it. So, Closure just uses common blocks to define what type an article or thing is. And you can describe interfaces in this way just like you would in a static language. And then the Closure Compiler can actually force that you’re passing the right type into the right function. And using this information, not only can it give you validation of your code or provide some feedback on correctness of your code, but it also can improve the minification capabilities. Because once the compiler knows about the structure of the code, it can change the structure of the code in a way that no other minifier can. And this is a totally crazy feature. And it does work in most cases. But this is not how code is developed outside of Google. JAMISON:  Sure. IGOR:  So, one thing that we leverage at Google is that we use these annotations to provide the injection tokens. So, one thing that you can do it any function in Angular that needs to be injected, you can annotate it with @ng-inject annotation. And then the compiler just knows that, oh, this function is to be injected so I need to preserve the parameter names in the string form before I mangle them. And that way, you get the safe minification that you were looking for. This is one thing. We made a mistake where we optimized for this use case rather than for the use case that is used outside of Google where you don’t use Closure Compiler to preprocess your JavaScript code. One thing that we however did is we just recently implemented a feature allows you to disable this [inaudible] token inference as we call it. So, if you turn this feature on, your application will not work unless you specify the annotations in a way that’s minification-proof. And this allows you to know that the application is not going to get broken by minification stuff. AJ:  Is that something for just Closure Compiler or is that for ngmin as well. IGOR:  No, this is for Angular. So, you can use it with any kind of minifier you want. You just turn it on in your application during the [scrub] process. And then Angular just knows that I’m not going to do any kind of extra work to figure out what it is that needs to be injected. And all the token identifiers for the injected services need to be provided in a way that is minification-proof. And then you can use any kind of minifier and it’s just going to work. AJ:  Okay. Are there other things like that in Angular aside from dependency injection where you’re doing some interesting mangling of code? IGOR:  So, dependence injection is not doing mangling of the code. All it does is by default it just reads the parameter names of the function or the constructor to be injected and uses the parameter name as the identifier to use for lookup for what is to be injected. So, let’s say you have some state in your application because all the applications have some state. And one thing that we tried really hard is to remove the global state from your application. Because once you have global state in your application, it means that you can instantiate only one instance of your application in a window. And it also means that if you want to reliably test pieces of your application, you need to create a new window, a new browser window or a new browser context for each of your tests. And this is super slow. This is prohibitively slow today. And this is why dependence injection is used in Angular so that we can remove the global state from the window. We have this other context which is used by the injector and the state is contained in this context. And this context is super cheap. It’s easy to reset. So, what we can do in between tests is we just reset the injector and the injector starts as if you were in a fresh window. And you can then reliably test your application without worrying that the previous test left something behind that will just interfere with tests now. And this makes testing much faster and much more reliable. So, for DI to know what is the state that you want, and the state in this case can be something as simple as HTTP service, HTTP service configured with some interceptors. So, let’s say every time in your application when you make a request you want to intercept it and check to make sure that you are properly authenticated. And if you are not, then you want to show a login screen to the user or something. By doing this kind of configuration, you create state. And this state is contained in the injector. Now, if your controller for example needs to make a request, it would ask for this HTTP service. But instead of looking on the window and saying window.http service, it just says, “I need HTTP service. [Someone now] construct it. Please provide me with an HTTP service that is valid for the current context.” And then injector is in charge of instantiating all these components. So, it would provide this right HTTP instance. And the way it knows that the controller needs HTTP instance is by looking at the argument of the function. Now, this is something that works well with Closure Compiler but doesn’t work with other compilers because we don’t have a way to annotate that code. So, what we did in Angular is we provide this additional way of annotating that this function is to be injected. And you can provide the identifiers as strings. And by doing so, the injector will then look and see, oh this function needs HTTP service as the first argument and will not look at the argument name. Does that make sense? AJ:  Yes. JAMISON:  That does make sense. AJ:  Actually. IGOR:  One thing that we changed in Angular 2 is we are no longer relying on parameter names and even on strings. And we want to rely on symbols in JavaScript. A symbol can be a constructor for example. And this makes things much easier to use and also much more robust. Because one thing that string annotations have a problem with is it’s easy to make typos. Whereas if you identify what needs to be injected using the constructor function for example, then you can avoid the issues with typos. SEAN:  So, one of the things that I’m interested in hearing a little more about, I was at ng-conf and I talked a little bit there about using TypeScript with Angular. And after hearing what you guys are doing both with these type annotations, the changes to the injector, and supporting ES 6 features, it seems like the vision of TypeScript and the vision of where you guys are headed with Angular are very closely aligned. I’m wondering how you see those working together and if you agree that they’re closely aligned. And what do you think the future of that is? IGOR:  There is definitely some alignment. TypeScript adds type annotations, which is something that we think is good for JavaScript as a language. We are not necessarily sure about the static nature of the type system that is used in TypeScript. Some view that that’s pretty much the only way to go because that’s what we’ve been used to. And even if you look at how Closure Compiler works, it’s very similar to TypeScript except that TypeScript actually extends the syntax of the language to provide the type annotations whereas Closure Compiler just relies on annotations stored in comment blocks. So, we definitely like the type annotations. And even in the experimental extension we created for the ES 6 language, which we call ES 6+A as plus annotations, we experiment with the syntax that is already used by TypeScript. SEAN:  Yeah. IGOR:  So, that is definitely good. We’re also experimenting with something we call a runtime type system, which is very much aligned with how JavaScript works today except that it adds some type of type checking. But this type checking is runtime. You can think of it as a glorified assert statement that is automatically provided to you by the language. And this assert statement is extensible and can say what it is that is being asserted. So, let’s say you have a function and you say that this function takes a first argument which is a user object. Now, what this runtime type system does, it just inserts assert as the first statement within the constructor that checks if the first argument is really the user. SEAN:  Yeah. IGOR:  And what user is, is up to you. So, you can say user is everything that is instance of user, or you can say user is everything that has name and email properties. So, this gives you much more flexibility than what is possible with static languages. And it allows you to do some of the validations that are impossible to do with static languages. SEAN:  Yeah. That’s really cool. I wonder. It seems like maybe there’s room for both because I’ve been using static analysis with my large JavaScript applications for a while. And it is correspondingly strong in a different area in that you don’t have to run through all your code. You don’t need complete code coverage to find errors. But it lacks the validation. And I think it seems like a complete solution to require both validation, runtime validation like you’re saying, and static analysis to catch things that aren’t in common code pathways. IGOR:  It’s very possible that the complete solution will include both. It’s still in early stages for us, so we haven’t really looked into how we can combine the two, aside from syntax. So, the syntax, how you specify the type annotations or how you annotate the call sites is very similar. But yeah, I think you’re right, that there is some room for collaboration, like this is complete coverage. On the other hand, in Angular we do try to aim for complete test coverage. And the goal of this runtime annotation is to give you assertion in a test environment. SEAN:  I see. IGOR:  So, the goal is not to run through these assertions in production. We actually want to strip all these assert statements before the code is prepared for production use because it doesn’t really add any benefit in production, if you have good test coverage because your tests will catch all the potential issues that could be caught by this assertion system. JAMISON:  So, there’s another sort of related system, the diary.js thing where it adds performance monitoring stuff that gets stripped out of production. Is that correct? IGOR:  Yes. But how is it related? It does exist. But it doesn’t… Oh, I see. JAMISON:  Just because it’s added stuff for development that gets stripped out in production. IGOR:  Yes. So, diary is a logging tool. And the idea behind diary is that if we had a micro-library that people could use to log statements, then we could collect all these log messages and then process them in some way or another depending on the use of the type of message or environment in which the code executes. And also, many of these debugging statements are not useful in production so it could be stripped just like the assertion statements for the type system. JAMISON:  That’s cool. Yeah, sorry that was kind of a tangent. It just popped into my brain when you mentioned things getting stripped off production. IGOR:  Yeah. So, in that case, in that way it is similar that many of these things that we are exploring are useful only in development when you’re debugging and stuff, or when you’re writing an application and you just want to get quick feedback on how you’re doing. But they don’t really make sense in production. And especially with mobile applications or bigger applications, every byte counts. So, stripping stuff that is not needed in production is definitely a big win. We saw this already in Angular 1.2 where we added a feature that strips verbose error messages. So, in development time when you work with Angular, you get nice error messages that will tell you a lot about what went wrong and what you need to do to fix those problems. But these error messages, nobody’s going to look at them in production. And they can weigh several kilobytes or dozens of kilobytes depending on the application. So, we decided that, what if we just strip all these strings for error messages. We still keep the statements that throw the error. But instead of keeping the long error message that is meant only for the developer, we would just keep an ID that would allow us to debug this problem if it should happen in production. And the way we do that, we create a special URL that you can click on and it will take you to a web application that will display, reconstitute the original error message based on the information it knows about the Angular version that you were using and the ID of the error. JAMISON:  That sounds magical. AJ:  Question about that, though. Often when I throw error messages, I like to put in contextual clues for myself. So, I’ll have the value of that variable be part of the message. It sounds like with that approach, you wouldn’t get any of those dynamic contextual clues. IGOR:  No. You still get that. So, the way we deal with that is the error is an interpolation template. You use it pretty much just like you would calls [inaudible] where you can pass multiple arguments where the first argument is the ID of the error. The second argument is this template that can be interpolated. And the rest of the arguments are arguments to be interpolated at positions defined in the template. So, you can still throw an error message that contains contextual information. AJ:  I see what you’re saying. That makes sense. IGOR:  We are able to recreate original messages just by knowing the ID and the values of these extra arguments that you passed in. JAMISON:  Okay. I have a question that is going in a different direction. You mentioned earlier when we were talking about minification how you built minification for the Google use case where everyone uses Closure Compiler and you can annotate functions to not have the argument names minified and things like that. How do you balance doing what is good for Google versus doing what’s good for everyone that isn’t in Google when you work on Angular? Are there other examples where you’ve had to weigh something like that, that this might make development at Google harder but it would make everyone else’s life easier or something like that? IGOR:  So, in the case that we talked about with the minification before, it wasn’t really a way to make development at Google easier. It just happened to work better for the Google use case than it did for the external use case. But in general, Angular’s an open source project. And I think we actually spend more time listening to the external feedback than we do to the internal feedback, which is crazy when you think about it because it’s a Google project. But we do listen to the internal feedback and we act on it. But most of the features that recently were added were added due to the external feedback that we got. And this might be because as an open source project, external people are more used to working with GitHub and working with us through GitHub. And the internal folks, they have to use this other channel to talk to us. Or, they can, there are many people from Google that work with us on GitHub. But I would say in most of the cases, Google audience tends to help each other internally. So, we have an internal mailing list and it’s separated from the external community. AJ:  Are you saying, is that part of Google Code? Or you guys do something else entirely internally? IGOR:  I’m not sure I understand the question. What do you mean by Google code? AJ:  I guess Google gave up on it. It’s their GitHub. IGOR:  Oh, oh, Google Code. It’s just [laughs]. JAMISON:  Oh, that’s a bad sign. [Laughs] IGOR:  No. So, internally we have a complete set of tools that I use for internal development. And we have internal mailing lists and internal review tools and continuous integration. Many of the tools that we have internally are [inaudible] compared to what’s externally available. But also, it’s just a different way of thinking about building applications than what is being used externally. And one thing that I think Angular had a big impact on Google was bringing many of the external ideas into Google that weren’t there. Because if you build so much infrastructure internally as Google did, then you can often end up in a Google bubble or you end up in a world that you’ve created for yourself that is so different from everything else that is being used outside of Google that you don’t even follow all the new advancements that happen outside of Google. And I think one thing that Angular did for Google was to bring many of the external advancements back into Google and showed people there are things that happened outside of Google that people just didn’t see or didn’t fit to the existing toolsets. But now Angular made it possible to use these approaches or APIs or tools internally at Google. AJ:  So, what I’m hearing is, because of Angular you guys are going to start using TypeScript soon. IGOR:  [Laughs] I don’t know about that. [Laughter] IGOR:  But who knows? Maybe. [Laughter] IGOR:  One thing that is cool about Google is that engineers get to decide quite a bit about their own projects. And I think the only thing that they need to weigh in is how well it fits into the existing ecosystem of tools and processes we have at Google. So, if somebody comes up with a way to take TypeScript and integrate it well into the existing infrastructure, then I don’t see why people would not use it if they thought that it was beneficial for a particular project. JAMISON:  Well, odes anyone else have any final questions? We’ve been talking for a while. So, this has been fascinating. I just know people have stuff to do. AJ:  So, I do have one, back to the error messages. In Angular, do you guys have some sort of messages in the 1000 range of this type and 2000 range of that type? Or is it just every time there’s a new type of error that you haven’t experienced before, boom you tack on to the end of it and that becomes the new code? [Chuckles] AJ:  Or do you not even have them at all and it’s just when it gets stringified, it becomes that code? IGOR:  Well, we considered several things. We considered using numbers, like number each message. But that doesn’t really scale well and also there are issues with collisions if multiple people introduce errors at the same time. We also looked at generating SHAs from the message string, but that is not very reliable because sometimes error messages change. So, what we ended up doing was just creating alphanumeric, usually abbreviation of error messages, something that makes sense if you just look at it. You don’t need to remember that error 43 is something, but if you see invalid ITPL or something, so invalid template, then you will know that oh, this template is invalid or something like that. AJ:  That’s nice. That’s a really good approach. IGOR:  Yeah. It’s been working really well for us. And yeah, as I said we looked at different options and this seemed to have the smallest amount of tradeoffs so that’s what we went for. AJ:  Cool. JAMISON:  Is there anything you wish that we would have asked you that we didn’t? Anything you really want to talk about we didn’t get to? IGOR:  Well, we were supposed to talk about contributions. JAMISON:  Oh, geez. IGOR:  And we didn’t really get to that. [Laughs] JAMISON:  We kind of did, but yeah you’re right. SEAN:  Yeah. JAMISON:  Do you want to talk about contributing to Angular specifically? IGOR:  I think that the main message I have is about contribution to open source projects in general. One thing that people think is that oh, if I want to contribute I just write a bunch of code and I send it over and that’s it, I’m done. And it used to work for us when we were a small project. But one thing that we realized is that as Angular grew and became more popular and we were starting to get more and more contributions, it became harder to babysit all these contributions and make sure that they’re something that we can actually integrate. And that’s when we starting doing a lot of automation around the project to lower the burden for us when it comes to reviewing contributions and determining whether this something that we want or not. Because there are many, many checks that can be automated. And I think in any project that is trying to be a successful open source project, you should start thinking about this kind of automation early on. Because this is one of the things that slowed us down last year, where we spent a lot of time building infrastructure around the project so that we can just deal with the amount of contributions we were getting. JAMISON:  You mean, continuous integration stuff to make sure that pull requests pass? IGOR:  Yeah. Continuous integration is part of it. One thing that we need is contributor license agreement. SEAN:  Oh, yeah. IGOR:  So, any code change means to have a signature from the author that we get all the rights to the code so that there are no legal issues. And many of these steps can be automated. And that’s what we did. We spent a lot of time automating all these various checks that we need to do in order to be able to integrate some change into Angular. And also, this is what we can do as project owners. But the individual contributors, they also need to consider, what is the style guide within the project? Or does the project require tests? If they do, then I probably need to write tests because otherwise somebody else will need to write the test before this can be integrated. And just in general be mindful of the contributions you are trying to make. I’ve seen many efforts where people were trying to encourage people to contribute to open source projects. But just sending a pull request with a change is not enough. If you want to be serious about your contribution, then you should also think, how can I make this change easy for the owner of the project to integrate it in? Am I following all these guidelines that are usually documented? Each project that is significant has some contribution guidelines. And just reading up on those and being familiar really helps the project owners to process all these contributions. One thing that we are doing in Angular constantly is we’re just being drowned by pull requests. And very often, it’s actually quite rare to just look at a pull request and see, oh yeah, this is good, let me just merge it in. it almost never happens. And people just, it’s easy to not see that there’s a lot of effort involved in just integrating all these pull requests. JAMISON:  So, I can totally understand how the goal should be to make your code… you’re playing in someone else’s sandbox. You want to follow their rules. That could also be intimidating to people that are maybe newer to open source or to development in general. IGOR:  Yeah. JAMISON:  Is there any way to, say I want to contribute to Angular, could I hop in the IRC channel, maybe ask for some feedback before I just submit the pull request that maybe I know has some problems with it but I don’t know how to fix them? IGOR:  We have angular-dev mailing list that you can contact us with. Many people also just start with smaller changes. And I think that’s the best way to contribute to any project. Start with small changes. Start with documentation fixes. Then gradually progress to bug fixes. And once you are familiar with the project, how changes are being integrated, then start to work on something bigger. And especially if you are working on something bigger, it’s always good to have a discussion about the work before you actually go ahead and do a lot of work. Because what I’ve seen in the past is that people go and they spend a weekend hacking on this thing and they create a huge pull request. And we look at it and we turn it down because it’s not something that is aligned with what we see the future of Angular, or it’s something that is not implemented correctly, or has other major issues that prevent us from integrating that change. So, any bigger change, or pretty much any bigger feature should be discussed ahead of time. JAMISON:  Is there an opportunity for a kind of mentorship? Just if you’re intimidated by throwing your code in and seeing it get criticized before you. IGOR:  [Laughs] JAMISON:  Does that make sense? IGOR:  Yes. The mentorship, usually pretty much the whole Angular team grew out of just people contributing on GitHub and then gradually becoming fulltime contributors. And the way it happened was people that would just look at things and they would see small issues and they would start fixing them and sending pull requests. And as we saw them on a daily basis or on a weekly basis and we saw their changes, then we start providing more and more feedback and tell them, “This is a good change, but maybe you could do it in this other way. Or maybe you could use this helper function that we already have instead of duplicating all this code.” And through this iterative process and working in small changes, you get to know people on the team. You get to receive feedback about your change. And you also learn about the project and the way the code for the project is developed. And this is how you can graduate to somebody who has commit access or gets to be a mentor for other people. And this is one thing that we are trying really hard on Angular, to get more people to the point where they are confident about making decisions about pull requests and can help us process pull requests. JAMISON:  Cool. That makes a lot of sense. Okay, let’s start off the picks then. AJ, do you want to go first? AJ:  Yeah. JAMISON:  [Chuckles] Okay. [Laughs] AJ:  So, I’m going to pick Google, but not because of Angular and not because of Gmail and not because they run my DNS and the Fiber to my home and pretty much my life. [Chuckles] AJ:  I’m going to pick them because of what a great job they’ve done in marketing Google Fiber in Provo towards the people that live in Provo. The thing that really struck out most recently is their April Fool’s joke was Coffee-to-the-Home. [Chuckles] AJ:  Kind of like the old RFC spec for Hyper Coffee protocol. They have the Coffee-to-the-Home protocol. But for Provo, Google Fiber, they made it Hot Chocolate-to-the-Home [Laughter] AJ:  Because we’re more hot cocoa drinkers than we are coffee drinkers. And there are other things that I’ve noticed in the advertising for Google Fiber to Provo that’s specific to the culture and the people of Provo. And I think that it is way, way awesome that Google did the research and took the time to make it feel more like a community thing than a big corporate thing. And I appreciate that a lot. JAMISON:  Sweet. I moved away from Provo, so I don’t have Google Fiber. Okay, I will go next. It’s called Geppetto. It’s a tool for developing when you have services. So, maybe you have a web of five or ten little services that are all separate repos and they’re even separate languages, have separate install steps configured with environment variables. It can be a big pain to get that up and running, especially when new people start working. So, my friend George made this thing to, you define some config and then it will basically install everything for you and run it with a shared environment. So, that’s my pick. Sean, what are your picks? SEAN:  Alright. So, I’ve been reading some cool web fiction lately. It’s self-published, which I think it’s awesome and it’s the future. So, you should go check it out and support the author. There’s a superhero story with a girl protagonist called ‘Worm’. And you can google worm or parahumans. And then he’s finished that one and now he’s writing his second novel called ‘Pact’. So, definitely go check those out. JAMISON:  Cool. Those were good picks that you did not pick last week. Good job. [Laughter] JAMISON:  Igor, what are your picks? IGOR:  I have one pick. I read a very interesting book recently called ‘Blindspot’. It’s a book about building implicit association tests. This is a test that helps you see how biased you are against certain things or certain people. And it was very interesting and eye-opening for me. It talks a lot about how our brain works and how people think, or people don’t think they think. And it’s a lot about how our brains our wired and how it affects the way we make decisions. One crazy thing that I learned from that book was that we use different parts of our brain when we think about people that we associate with or consider to be in our group and we use different parts of brain when we think about people that are in a group that we don’t associate with. The test is online, so you can run the test and see how biased you are against certain races or old people or many other groups of people. And it was very eye-opening for me to see how our brain works and how it affects the way we make decisions. JAMISON:  That sounds fascinating and also a little terrifying. IGOR:  [Laughs] I totally agree. It was… The curious thing is that we don’t realize how much is happening in our brains without our knowledge. JAMISON:  Sure. IGOR:  And how our brain just makes us make certain decisions. And we think we are fully in control but we are not. [Chuckles] JAMISON:  Sure. SEAN:  Yeah, we like to think of ourselves as inherently logical creatures. But you’re only logical to a certain extent, or as they say rational. To be really rational you have to not only think clearly but correct for the ways that your brain deceives you. IGOR:  Yes. JAMISON:  Well Igor, thank you so much for coming. It was really great to talk to you. I learned a lot about Angular and about open source stuff in general. IGOR:  Sure, thank you. JAMISON:  And now I have a scary brain test to take. IGOR:  [Laughs] Anytime. AJ:  And I learned that even Google doesn’t remember about Google Code. [Laughter] [Hosting and bandwidth provided by the Blue Box Group. Check them out at Bluebox.net.]  [Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.] [Do you wish you could be part of the discussion on JavaScript Jabber? Do you have a burning question for one of our guests? Now you can join the action at our membership forum. You can sign up at JavaScriptJabber.com/jabber and there you can join discussions with the regular panelists and our guests.]