053 AiA Angular Apps That Scale with Ben Drucker

00:00
Download MP3

Check out RailsClips!

 

02:24 - Ben Drucker Introduction

03:00 - What is meant by “Angular apps that scale”?

04:54 - Tools

06:25 - Ben’s Background in Scalability

09:28 - “Scalability” and “Scaling”

14:00 - Team Size

14:53 - EAZE

17:00 - The EAZE Architecture

21:17 - What You Should Be Doing to Scale (Tips)

  • Documentation
  • API Answers the Right Questions for the UI
  • Versioning Strategy

23:45 - Managing Scale (Monitoring Load)

26:58 - Server-side: Data Storage

28:58 - Client-side

  • Dependency Injection
  • Naming Collision and Conventions
  • Build Process 37:24 - Ben's GitHub Repos and Open SourcePicks

Robots on the Line (Joe)Saint Petersburg, Russia (Katya)The Man Who Saw America: Looking back with Robert Frank, the most influential photographer alive (Ward)Paracord (Chuck)Soto Pocket Torch (Chuck)Shyp (Ben)

Transcript

JOE: Roll! Roll it! JOHN: Roll. CHUCK: Roll take![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.]**[Does your team need 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 -- AngularBootCamp.com.]**[This episode is sponsored by Wijmo 5, a brand new generation of JavaScript Controls. A pretty amazing line of HTML5 and JavaScript products for enterprise application development. Wijmo 5 leverages ECMAScript 5 and each control ships with AngularJS directives. Check out the faster, lighter and more mobile Wijmo 5.]**[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!] **CHUCK: Hey, everybody! Welcome to Episode 53 of the Adventures in Angular show. This week on our panel, we have Joe Eames. JOE: Hey, everybody! CHUCK: John Papa. JOHN: Hey, everyone! CHUCK: Ward Bell. WARD: Hello! Hello! CHUCK: I'm Charles Maxwood from DevChat.tv. Just a quick shout out while I've got the mic, I released RailsClips, which is a video series on Ruby on Rails. I know this is an Angular show, but some Angular folks do Rails. So, if you're looking for videos about Rails, go check it out at railsclips.com. I forgot Katya. Katya. KATYA: Hi! CHUCK: I just can't see her there with Joe. JOE and KATYA: [Laughs] CHUCK: We also have a special guest this week, and that's Ben Drucker. BEN: Hey, guys! CHUCK: Do you want to introduce yourself? BEN: Yeah, absolutely! I am an engineer at EAZE at the moment. We're working with a full JavaScript stack, Node Angular, and some other new and exciting stuff. I just moved to San Francisco to join the company. And, I've been doing JavaScript development front end and backend for better part of, I would say, 2 years at this point, got into it, realized it was a wagon worth hitching to and haven't went back. CHUCK: Very cool. We have on the doc "Angular apps that scale", and it seems like a lot of people tell the single page app is scaling because you move all of that logic in computing to the front end so it's executing in somebody's browser so you don't have to do that work on the backend so it's scalable. So, if Angular is inherently scalable, then what do you mean by "Angular apps that scale"? BEN: There's a very different meaning, for sure, on the front end. If you do your backends appropriately, the scaling advantage there is that you have very little state in your applications, you can spin up lots of new boxes, and you can just scale by throwing computing resources at it on the front end you're dealing with, one computer, one user, but you have lots of state. So, scaling to me on the front end means how do you manage this dramatically more complex application. Because on the backend, everything is a black box to the user so you can break up your backend into a hundred different services or you can leave it as one. At the end of the day, the user really doesn't know the difference on the front end, like everything is running in one place. So, it's really a matter of how you organize the application itself in code as opposed to how you split it out into separate services that have some protocol for talking to each other. What I found is that, really, it's the name of the game when it comes to building applications that make you tear your hair out. It's not about servers crashing due to load. It's about managing complexity because your applications can be one thing on day 1, and by day 365, if not quite a bit sooner, it's going to be something insanely different. So, how do we cope with that transition? CHUCK: Are there particular tools that you recommend for this? BEN: Yeah! I think the starting point is a module loader of some kind. I think, using one is a whole lot better than using none. There's Browserify out there, which I really like and we use it at EAZE and I've used it personally for quite a while. There is AMD and RequireJS, which has been around for a while. And, there's new things that are trying to provide for compatibilty with what ES6 wants to do on modules. At the end of the day, it's some sort of system that allows you to break the application into smaller parts, and that system is smart and it knows how to assemble your application. At the end of the day, you don't have to tell it your oldschool, "Here's where our old MyScript files are, make them into one big thing," it needs to be smart enough to go to each package in the tray, find all the dependencies, and keep moving along so that your application can treat these different bits of it as black boxes that expose a certain API and you get to consume them, and it's easy to consume them. It's a simple statement whether it's a Require or an Import or something like that. You have a concise and one-line way to bring in third-party code. WARD: Certainly, I get that, and that distinction also between how you modularize versus dynamic or async loading of scripts. But, can we back up a little bit to what you're working on that has led you to be thinking about scalability with this technology? BEN: I originally got into this whole world of breaking applicatlions into smaller pieces at the last company that I worked on called Ballet where I was producing donation tools for non-profits, and along the way, started to break out a lot of the core business logic into open source packages. One of them that's proved to be popular is Angular credit cards that was a huge piece of the business as not only processing credit cards, but trying to surface typos and various other error states from users as soon as possible because if you tell them right away, they can fix that, whereas if you report some sort of generic server error, it's slow and hard to understand. That was the case where I realized that nothing was especially technically difficult. Validating credit cards is some simple string computation and a lot of regular expressions. The real challenge with that particular business was not doing something computationally intensive or something that really required intense thought. It was  more about how do I break these pieces apart so that I can get a handle on what I'm building so I can write test across all these things that are going on because I thought I could left it in the core of the application, it was just going to become completely unmaintainable. There is going to be so much logic that was completely unrelated to the business itself stuck in the application. I was working on it solo so I was working very hard to try to manage my attention, and my time are on the code base knowing that if I really screwed something up, I really didn't have extra dev time to be spending. It was about moving fast and having the ability to independently version pieces and just juggle a lot of balls at once. WARD: So, this is the case for separation of concerns kind of thing, right? Building modules that are focused on a single problem and not mixing that code up with other code that's working on other problems. That basically what drove you here, right? BEN: Correct. How do you just acknowledge that certain pieces of the process are going to move faster than others and requirements are going to change, sort of how can you anticipate failure from day 1, expect to be wrong about a lot of decisions, and have a comfortable way to recover from those incorrect judgments as opposed to getting stuck doing rewrites of uncomfortable refactors. WARD: Okay, I think we all experience that in our code. When we think about scalability -- well, a lot us have a different ideas about what that means -- what does that mean for you in the context of that application you were describing? BEN: I think it hinges on my idea of expectiing for the ground or shift underneath you and for things to change. Very rarely do applications actually encounter legitimate performance challenges on the front end. Most of the time, you're not dealing with really complicated data processing or things where you're thinking about how to make maximally efficient use of the computing resources that you have, the problem that's going to trip up, your standard business or consumer application where you have some forms and you have dynamic data flowing in. It's the glue that sits between the pieces because you're building this tower over time where you're going to tack on all kinds of additions. If you do that quarterly, you're building something that's vulnerable to surprises. So, you may decided to add a particular feature and find something that seemed like it should take a day, it turns out to take a week worth of untangling mixed concerns. So to me, front end scalability means how do you work with that constant change and how do you think about growing an application that will proabably start pretty simple, and by the mid to end of its life cycle, be extremely complicated. WARD: That's clarifying in terms of what you mean, and it helps us separate from another meaning that often in people's heads, which has to do with how many users, simultaneous users, do you have and what kind of pressure that are put on backend resources and stuff like that, which is certainly a very real problem for awful lot of companies, and that tends to be what they mean by scalabiity. But your focus is on scaling up a complex application from a development perspective. Is that a fair summary? BEN: Yes. And I think even on the server, when you're thinking about concurrent users, the path to achieving some scalability is to break the application into multiple pieces so that the piece that actually has the most computational pressure on it, you can put the appropriate resources behind it so message queing whatever you need to do. JOHN: Ben, I'm kind of a lot of an [incomprehensible] questionnaire's point. I think I'm following where we're going, I think that can go a couple of ways, the way you're describing scaling. Are you saying scaling, not in as far as users, but are you talking more about the goal being maintainability, creating more enhancement slater, or in deployment DevOps. How would you one-word summarize the goal of the scalability you're talkinga about? BEN: I think maintainability is per-analog, but maintainability itself coulb be split into 2 pieces. There is your ability to add the service of features and changes that a user would recognize, things that have fault reaching or even small changes to the end-user experience in the applcation, and then there's also the somewhat obscured from the user's issue of bugs, and I think that's something to think about as well as you talk about scaling and application; the temptation is always to just in-line this simple function that you think you understand today. The question is, will you need that function to do something else down the road? And, how many scenarios are you able to test? How well is your code able to adapt? And for a feature, that means like adapting the pixels on screen for a user, but for internal APIs, you're talking about changes in the way that you're gluing the pieces together, and how much, when you add something, do you need to know about how old those internals work? And in order to know that information, can you look at test or documentation? Or, do you have to read and understand every single line of the source code, or have any stance of what will happen when you take a particular action? WARD: Are you designing for teams? How big is your development team typically? BEN: Team size actually matters, but the more important thing is the general trend regardless of team size, which is when you have this product or building a company, and it turns out you should actually building 4 different applications each of which is focused on a particular user group, whether if it's a market place, you have one thing for your sellers and one thing for your buyers. Something to that effect is quite common at this point and the highest level of modularity; rather than builiding one app, you're going to build a couple of apps, and then the question becomes how do you share between those applications, because there are inevitable overlaps, how do you match them? WARD: Let me back up a little bit from that -- maybe I'm switching gears on you -- when you think about the application, perhaps the application that you're now building at your current company, which is EAZE, right? BEN: Yes. WARD: It would help us a little bit, I think, to understand the broad architecture because you really think of this application in the end to end perspective, not just on what's being developed on the client. Can you give us the big picture behind the architecture of EAZE, then we can fit this back in. BEN: Sure. I think I should start by giving people the 30-second run through of what EAZE is and what we do as a company. EAZE is a medical marijuana technology company. We are the "Uber for weed" as been quoted. And that means -- WARD: [Laughs] Ahhh... Do I need to be a driver? How do I sign up to be a driver? BEN: You would have to be in California to be a driver, but the mechanics are very similar. So, a huge chunk of EAZE's value is fast and reliable delivery time, drivers are on the road running a mobile application, they're having orders coming to them in real time. As a medical marijuana patient, you're placing an order through a mobile web application because of the App Store and Play Store rules, you actually have to have this as a mobile web application. So from mobile and desktop, pretty even slip between them, so you're placing an order there. About order, it's dispatched from this front end application to an API, that API sends out the order to native mobile applications that drivers are running, and then there's a lot of administrative effort to understand how orders are flowing to do quality control and just manage the user experience to [incomprehensible] as possible. WARD: Well, it sounds like you're going to have a great cross-sell with pizza... BEN: Yeah [chuckles]. CHUCK: [Laughs] WARD: [Chuckles] So, behind all of this -- I know, for example, that Uber is running nodes in the back and then other stuff in the front -- what if you got behind the scenes there propelling your application? BEN: The engineering team is full JavaScript, and that's changing from some original Microsoft stack pieces. So, EAZE was actually built originally by contractors so certain services were built by the current engineering team in-house from day 1, and certain services were initially created by contractors, and we're playing dual roles in supporting them. So, I would guess by, maybe, the end of this year, it will be 100% JavaScript. Right now, there are still a couple of bits of that, to us as an engineering team, are essentially black boxes that we don't deal with directly and we're just making API calls and not worrying about what's going on behind the scenes. WARD: So, is my Angular client is it talking to a node API? Or, a single node server? Is it talking to a multiple node servers? How does it flow? Like, I'm sitting here with my client app and I'm making a call to the server, am I making it to a single server or multiple servers, first of all? BEN: Right now, it's a single server but EAZE actually has 2 products so there are entirely independent APIs for those issues. There is eazeup.com, which has been around since day 1, and that's your ordering system. And then very recently released is eaze.md, which is a system where you can actually go online, have a consultation with a doctor directly in a browser, and get a medical recommendation that you can turn around and use immediately on eazeup.com, if approved. For example, right there, EAZE MD has 2 backend services -- one for the REST API and one for the Web socket communications that needs to happen there, and those are entirely independent from the primary API, which is still one single large application. WARD: Are you finding, if you run that step, that you're getting -- where are the bottleneck showing up? I assume you guys have been in production, you're taking orders and so forth. BEN: Yes. EAZE has been around for quite a while at this point, actually a young company, but quite a while for this [incomprehensible]. We quickly become the biggest player here and gained thousands of orders. The big bottleneck at this point that we see as a team is around this issue of growing the business and changing from a single simple application, but could be duct taped together by humans doing customer support and just growing fast enough that customer support is no longer able to solve a lot of problems. Initially launching in San Francisco, and now, at this point, in San Francisco, San Diego, and Los Angeles, in select areas at San Diego and Los Angeles growing to basically the whole metro area in both those cities this year. The volume of orders is going through the roof, so there's a lot of emphasis on solving all of the technical and design as soon as possible because we can't solve small order issues anymore by just having an email conversation with somebody; we need to be at the level of Uber where it's a perfect experience 99.99% of the time, and that business can scale where there's one that requires regular support and intervention can't. JOHN: I'm going to switch gears a little bit... BEN: Sure. JOHN: Because that's what I like to do [chuckles]... Just taking up a little bit, we talked about scaling a little and we talked to what your company is doing, and I assume you're applying some of those principles to what you're doing with that EAZE and your previous ventures. If you had to give our listeners a couple of tips, let's just say your top 2 or top 3 tips on when you're trying to scale an app in the way that we've defined it here, what are those things that they should be doing that they're not today? BEN: I think the over arching principle is to focus intensely on the glue between the parts and less on the individual part. If you connect everything properly, oftentimes, you can take an ocassional short cut, and leave a comment in there mentioning that you need to come back. When we say API, as you're a late person, maybe people know, at this point, that it's like some HTTP service that's doing something for your application. When it comes to front end, obviously, we're mostly constructing APIs and consuming a few APIs in the forms of frameworks. So, you want to think really carefully about the API of your application in the same way that somebody might think about an API if they're, let's say, stray portfolio where you can't change that API without serious clasping involved. You have to have some sense of versioning, you have to have documentation, and you should really think about front end applications or backend for that matter in the same way. So, you should think about how you can provide maximum feature proofing from day 1 and acknowledge that the internals will change, but the externals shouldn't. JOHN: Sorry, Ben, I just kind of see if I heard you right there. The tips that come out of there that I think I gather, correct me if I'm wroing, is basically to make sure you've got documentation for your API and make sure your API answers the right questions for your UI trying to answer, and also make sure you've got a versioning strategy in place so you can manage your growth over time and handle backwards compatibility to whatever degree you want to do that. Is that what you were saying? BEN: Yeah, I think that's exactly right. JOHN: Okay. I think I can agree with that as being a concern as well. I'm curious, what kind of load are you guys seeing or either [incomprehensible] your current company where when you say, "Hey, I need to worry about scale of size," what kind of load or number of request per minute, how do you monitor this stuff? Can you talk a little bit about how do you manage that kind of thing when you get to large scale, not designing it, but how do you manage it? BEN: You, I think, had a lot of affordances in 2015 as computing power gets cheaper. I think, in a lot of cases, when you're talking about backend services, you can just throw more CPUs and memory at a lot of problems, unless it's a Facebook-style, really difficult, tons of data problem. So I think, managing scale, it's actuallly more important not to focus on being able to contain problems. So when a particular piece has a performance issue, is that piece well isolated? And if we're talking about backend, if it is well isolated, you can put message queues in front of it and you can spin up more and faster boxes to help cope with that load. You can do that very inexpensively. JOHN: Okay, but how do you know when to do that? I guess my point is, are you using any kind of tooling to monitor load? When you're making a decision at some point to go ahead and do, let's say, more CPUs or more VMs or more message queues, what's telling you to do that? What's that [incomprehensible]? How are you being notified at that? Is there some tool you're using? BEN: I think it certainly helps to have automated tooling for the alarm bells issues where something is going really, really wrong. For other issues, I've found that it's most helpful to just have some regularly scheduled performance auditing about you're doing where you take a look at your response times, maybe you set a 95% threshold that you think is acceptable, and inevitably over time, you're going to start doing more things and you're going to put more pressure on that threshold that you've set. And when you start to peak above at threshold that you've set as an acceptable latency or response time whatever your metric is, at that point, you just do some target investigation for the single highest leverage optimization that you could make. In some cases, that might just mean spending a half day on one particular thing, but I don't think it's entirely necessary to do that from day 1. You should anticipate from day 1 that every single component might be the culprit, but you don't necessarily need to go make everything absolutely perfect until it turns out that that component is indeed the culprit and it's the lowest hanging for better performance. WARD: Ben, I want to ask you one more service-side question and then I'm going to spin it back to the client-side for a brief bit. My curiosity on the service-side is, what are you using for data storage? Is it SQL or no SQL, and anything you can say about that? And then I'd like to come back to the client, but I have this need to know. What are you using? BEN: At EAZE, we are using RethinkDB pretty heavily for the advantage of having no SQL and is also very real-time friendly. In the past, I've worked very heavily with Firebase and I do a lot of PostgreSQL, so we're also doing SQL at EAZE for a lot of things as well. It's really a question of what the needs are. For real-time application, the front end database in a lot of cases would be Rethink, but ultimately it would be shipping data out to a SQL database for analysis. It really depends on the need and what data are we looking at on a regular basis versus what things that don't necessarily need to be real-time. WARD: So the real-time stuff, like would orders be in both? Or, are customers be in both? Would they be in one or the other? How do you make that decision about which kinds of data belong and which kind of data repository? BEN: Things like orders and customers typically are very relational and it makes much more sense to store those things in SQL, whereas, for example, with the EAZE MD product where doctors and patients are connecting in real-time and you have chat going on and all these interactions are happening live, there's not a lot of need to query that data in flight; it's important that 2 connected clients get this information, and then at the end of the session, that information gets shipped off for analysis, but it's not necessarily critical that you'd be able to make SQL queries on those active sessions so that it informs that decision there. WARD: Got you. Let's swing over to the client where your app is primarily Angular. Does Angular do it all for you? Or, do you fee that we should be aware of something else going on? BEN: I think people should investigate the module tools out there. What Angular is giving you is Dependency Injection, and I think that, in a lot of ways, not without its uses, but a lot closer to the web development that we think of as completely unequated and never something that we would do in 2015. So, it's pretty well agreed upon that it would be a bad idea to publish every single service in your application on the window. Nobody is really doing that in 2015 [inaudible]. WARD: I'm sorry, I'm not quite following you there because I understand Dependency Injection is being compatible with your earlier idea about modularizing things and then just injecting the module that does like credit card or whatever wherever you need it. So I'm not sure, what am I missing here? Is this a critique of Dependency Injection? Or, you're trying to say something else? BEN: Yeah, it is a critique of Dependency Injection. You could still follow the idea of having single responsive ability modules and functions, but you would just publish everything on the window. You would say, window.request and you'd put your logic in there for calling the server or whateverr you need, and it's pretty well-understood that that's problematic... WARD: But nobody in Angular would ever do that, right? BEN: Correct. WARD: Nobody in Angular would ever do that. BEN: Yes. Dependency Injection makes most of the same mistakes as that like various simplistic approach, but it's less obvious. Dependency Injection has a single global name space for all of Angular and services have to be name spaced otherwise they break, and you only have one global registry. Let's say we have our application at the top and then one of our downstream dependency is something that registering as a dependency of our application has modules that it depends on. With the Angular Dependency Injection system, those dependencies of dependencies can clubber our own services without our knowledge and... WARD: If we don't name them according to some convention that keeps them from having a name collision. BEN: Correct. WARD: So, is the critique that there is the risk of name collision unlesss we adhere to conventions that prevent that from happening? Or, you're saying that even using naming conventions runs you into trouble? JOHN: Well, two people use the same name convention... BEN: Even using naming convention, in the most extreme case... Right. Let's say you go to the most extreme pole and everything in your Angular application is given a completely randomized name -- there is basically no probability of collisions -- you still create issues where, as a top level application, when you depend on a module, everything that that module has automatically gets exposed. There's no way to have private dependencies in the system. Everything is entirely global. So if I just want a little utility to do something inside my module, Angular Dependency Injection doesn' help me with that; I just have to in-line the function directly. There's no sensible mechanism for making something private in a way that can't have name space collisions, but also it's very clear that it's not exposed from public consumption. WARD: Okey. Yeah, that's certainly true. I don't know that I've experienced that as a problem, but maybe I just missed it. Anyway, what are you doing that alleviates that problem? BEN: I use Browsertify exclusively for front end applications. That means that you're able to compile node modules so that they run in the browser and you're able to use the Requre function from node in order to import a module into a particular file that module is local to that file, there is a defined syntax for what you export so it's easy to get various small things, whether it's "I want a camel cases string and I just want something that does that one single little function," or sharing code between your nodes and your front end applications. I think, actually, more often than not, it's the former case of just bringing in lots of little utility functions. But for a lot of things, especially related to data and sharing a validation and Schemas and things like, it can be enormously helpful for sharing code between server and the client as well. WARD: So the client is actually running node on the client? Is that right? Or, is there something else? Not all of us know what Browserify is doing for us in this regard. BEN: If you have a compile step where you're giving Browserify an entry point and it is taking that entry point looking for all of the Require statements inside that entry point -- a specific file, or a blog -- and then traversing those pieces in order to ultimately build one big chunk of JavaScript. There is no node one time that's happening in the browser; it's basically wrapping things in Closures  and creating internal registry of these pieces so that there is a Require function that's defined inside of the code that are outputs. And when you run the code, Require internally works the way that it would work in node just as at the dependency is that it'll need to go get have actually been in-lined so that it's not dynamic, it's entirely asynchronous. WARD: And how do you tie that back in to -- as an Angular programmer, what am I experiencing is being different there. I still have controllers, right? Yes? No? How do I integrate my Angular code style with using these Require statements? BEN: High level Angular concerns like having controllers and services would not change. The most notable change is that for modules that properly export in a node compatible format, which Angular, all of the various split off Angular packages like the router do -- do I router this amongst some other popular third-party, plugins. What you would be doing actually is, from those packages, you would export the module name. And then in your app initializations step, when you're saying "Angular.module" or you're giving an application a name and you're creating an array of dependencies, you're actually able to insert those Require statements directlly inside the dependency array. The result being that your third-party dependencies will be loaded with Angular and then you will return the actual name that needs to be in that array so that the Dependency Injection system can be happy. You actually get to do that in one single line, and then the build process will basically automatically figure out how to assemble your bundle as opposed to you having to tell some build tool "Here all of my third-party dependencies in order of how they need to be registered," which gets quite very long. WARD: Thanks! I guess I had one more question. We went to the GitHub site and you got 304 GitHub repos [laughs]. That's a lifetime's worth of work for some of us. How did you get to that? And what advice do you have for us? How do you even get there? BEN: I think it's about building the shipping muscle for one and just getting very comfortable at least in packages. I think unlike any other habit on day 1, it's really hard. A year or not even a year [inaudible], it could be considerably easier. For me, that means having all kinds of helper scripts, shell scripts, some JavaScript to help release this stuff because I'm following a very consistent set of standards across all of these packages. So, that's just something that you have to find over time. It's entirely possible that with the exact same knowledge of what we want to build, I could have something published to npm in 5-10 minutes that might take someone who's doing there, first or second open source package, it might take them 30 or 40 minutes, if not more, just because I'm very used to doing things this way, so that definitely helps. I think the other one is just not treating open source as this name brand activity where everything either has to be Angular or React, or it has to get hundreds of stars. I think it can be extremely helpful to think about open source JavaScript these days as the evolution of this snippets that people used to have in their text letters where we're trying to create all of these Lego bricks that are individually well tested and documented. A lot of the things that I'm publishing qualify a snippet where to a lot of people who think of open source as Angular or React or projects that take a ton of time that might seem a little bit unusual. But to me, it wouldn't be at all unusual to publish something that's 2 or 3 lines, maybe 5 or 10 if it's useful and if it helps take a classic tricky problem and make it a little bit more understandable, then it's worth open sourcing. WARD: Well, that's better than what I was going to do. I was just going to go out and fork the most popular app. BEN: [Chuckles] CHUCK: [Laughs] WARD: It just builds up my repertoire that way. Well, thanks, Ben. That was certainly an interesting survey of the scene! Chuck, where are we? CHUCK: I think we're ready to get to picks! Let's have Joe start this with picks. JOE: I'm going to pick a board game that I've had for quite a while. I actually kickstarted it, and the guy that I know who works for Pluralsight, or used to, I think he used to work with Pluralsight, actually created it and it's called "Robots on the Line". It's a really fun game for one reason: because you can play it in lots of different ways. It just has all these little tiles that you connect together to build up robots, and there's a lot of different ways to play it. But it's a really fun game to play with kids. It's very entertaining for adults, but it's also really fun for kids to build robots together. They're just a little cardboard tile so it's not like any kind of real robot, but still fun imagination, and the parts are all drawn in a cartoon-y fun style. Just a very enjoyable board game to play with kids. That's going to be my pick. It's the board game Robots on the Line. CHUCK: Alright. Katya, what are your picks? KATYA: My pick is going to be "Saint Petersburg, Russia" because I was there about a month ago, and it's a beautiful city and I want to go back. CHUCK: Very cool. Ward, what about you? WARD: Well, clearly, we're not doing any technology today. I am going to paste in a link to an esasy in New York Times about Robert Frank, who is a, in the '90s, he was a very influential avangard photographer who's major book was something called The Americans Back in the, I guess it was in the early '60s. He was a friend to the Beats, friend of the Rolling Stones, but a pretty strange character. I think when you read this essay, you'll want to know much more about him and you'll be very interested in getting his seminal book, "The Americans". CHUCK: Alright. I've got a quick pick, and that is "Paracord". You can buy all kinds of colors and designs on Amazon. The way I got into it was funny. I do the training for the cub scout leaders at round table, which is just the training meeting every month for cub scout leaders. One of the other people on staff is really into paracord so he was tying stuff. We did a Round Robin where people could pick the sessions they went to, and his session was actually tying a fab for your keychain in paracord. I couldn't go to it because I was doing my own session, but afterward, he helped myself and few other staff members tie that and turks had a while ago, which you can put on your neckerchief as a neckerchief slide and stuff like that. It was a lot of fun so I'm going to pick "Paracord". And he also had this really cool case for a Bic lighter. You slide it in there and then you put the lit, the cap on, and then it has a button on the back that when you push the button down, it access a mini blow torch... WARD: [Laughs] CHUCK: [Chuckles] Yes, it's really cool. And I just thought it was cool; it melts paracord really nicely [chuckles] as you can imagine. So, I'm going to pick that, too. I'll put a link to that in the show notes. WARD: That's fun. That's fun. I've gotten in knots recently myself for some reason. I have like my favorite knots that I try all the time. I guess that's related, like Back at Hitch, I'm going to flip them in there. Back at Hitch, Slippery Half Hitch, and everybody got to know a Bowline, right? CHUCK: That's right. WARD: If you don't know a Bowline, you're going to lower yourself down the cliff, which we all are doing in code everyday. CHUCK: Everyday. That's right. Yeah, so I'm going to be tying a few more bracelets and stuff. Eventually, I want to tie a belt, doing an entire belt. WARD: So, you're into bandage. I get it. CHUCK: That's right! [Laughs] Ben, do you have some picks for us? BEN: Yeah, absolutely. One that immediately comes to mind is, I just moved from New York to San Francisco this week, and a life saver was "Shyp", spelled S-H-Y-P. It is a service that will basically send somebody to professionally package and ship your items for a $5 for pick-up fee, they send it via usually USPS or FedEx, whichever ends up being cheaper. Essentially, it's a bike messenger, shows up, gets your stuff, takes it, off to the shipping depot where it gets packaged and sent out. They are in San Francisco, New York, Miami, and LA right now. With this, it basically saved my life where I just really did not have enough stuff to merit hiring moving them. I think this is probably true to a lot of people in cities these days, and it would've taken probably 2 entire days of my life to go buy a bunch of boxes and tape and try to stuff everything in myself. So Shyp basically, pretty much lived in my apartment for the last week or so, picking up stuffs that I was selling online or shipping to myself out here. It's pretty insanely cheap for what it is. It will be exciting to see it spread outside of those couple initial cities because it's one of those things that we don't do on a daily basis. And then once you have to do it, it's a huge hassle. So it's yet another on-demand service that is making life in 2015 pretty great. CHUCK: Alright, cool. Well, if people want to follow up on what you're working on or find out more about what you do, where should they go? BEN: Best place to start is probably on Twitter @bendrucker, D-R-U-C-K-E-R, and you can make your way to my website. From there, you can check out EAZE at eazeup.com, and I'm starting to get back into doing a little bit of writing so we're working on a lot of interesting things at EAZE. Some of our applications are Angular, some of the new stuff that we're working on actually is not Angular, and it's not React either, so I think there'll be a lot of interesting things to talk about around of what EAZE principles of modular and breaking up that applications to small pieces, what is that actually look like for a company that's growing really fast. CHUCK: Alright, cool! Well, I guess that's the show so we'd wrap it up and we'll catch you all next week![This episode is sponsored by Mad Glory. You’ve been building software for a long time and sometimes it gets a little overwhelming; work piles up, hiring sucks, and it's hard to get projects out the door. Check out Mad Glory. They are a small shop with experience shipping big products. They're smart, dedicated, will augment your team, and work as hard as you do. Find them online at madglory.com or on Twitter at @madglory.]**[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 wanna 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.