049 AiA Line of Business Applications and Developers with Deborah Kurata
02:14 - Deborah Kurata Introduction
02:32 - Line of Business App Developers
04:24 - How do these apps look different?
07:20 - Forms Over Data and Business Rules
- Delivering Features and Ease of Development
10:43 - Learning Curve, Tools
13:24 - Forms Over Data (Cont’d), Using Angular for LOB Apps
17:57 - NuGet Package Manager
21:17 - Training Newbies in Angular
22:31 - Features of Angular Most Important to LOB Devs
- Two-way Databinding
- Modularization
- Routing
24:01 - Custom Directives?
24:34 - Grids
32:33 - Cons of Being a Line of Business Developer
34:11 - OData
35:28 - Where Angular is Going and Where Microsoft is Headed with It’s Tooling
42:59 - Deborah’s Thoughts on Using Angular 2
- Pay Attention to TypeScript Picks
Camel Up (Joe)Exploring ES6: Upgrade to the next version of JavaScript by Dr. Axel Rauschmayer (Lukas)Zapf Video From 1960s (Ward)Just My Type: A Book About Fonts by Simon Garfield (Ward)Essentialism: The Disciplined Pursuit of Less by Greg McKeown (Chuck)Angular 1.4 (Deborah)
Transcript
LUKAS: Anybody? Crickets? WARD: [Laughs] LUKAS: Okay, I'll work on my materials some more.[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 49 of Adventures in Angular. This week on our panel, we have Ward Bell. WARD: Hi there! CHUCK: Joe Eames. JOE: Hey, everybody! CHUCK: John Papa. JOHN: Howdy! CHUCK: Lukas Reubbelke. LUKAS: Hello! CHUCK: I'm Charles Maxwood from DevChat.tv. This week we have a special guest, and that is Deborah... I should've asked how to say your last name... Kurata? DEBORAH: That's close enough! CHUCK: Do you want to introduce yourself really quickly? DEBORAH: Hi! I'm Deborah Kurata, I'm a consultant and software developer in the San Francisco Bay area. I'm also a Pluralsight author, and I really love Angular! CHUCK: Nobody on the show likes Pluralsight authors. DEBORAH: [Laughs] CHUCK: We brought you on the show to talk about, I think in the email you said "Business app developers", in our pre-show discussion, we were saying, "Line of Business developers". Do you want to give us a brief explanation of who these people are and how they're different from maybe other developers that we think about in other industries, or other areas of industry? DEBORAH: Sure. When you think about Line of Business application, you normally think of applications used by business users to perform various business functions. These are different in that the expectation is that they're developed in-house -- small companies, medium-sized companies, and some large companies that are doing custom development to support their businesses. Unlike companies who's software is their business, these companies have a business doing something else -- making widgets or whatever, and restaurants or managing properties or whatever -- and the software is there purely as a support mechanism and a cost-center more or so than a profit-center for the entity. These business software developers or Line of Business developers then are the developers in these small, medium, maybe a little bit larger companies that are developing all of this software for use internally. CHUCK: That's really interesting because most of the companies I've worked for, and I'm a freelancer now, still most of the work that I've done is, we're building the product. So they're usually willing to pour more money on us in order to make more stuff that they want. It seems like the Line of Business folks wouldn't have those kinds of opportunities. Maybe they would. But how do these apps then look different from the apps that we're dealing with as software developers that build the product that is out there on the web for everybody to use? DEBORAH: Well, frequently, because of exactly what you just said, they aren't given huge budgets for these things because they are considered frequently to be cost-centers. So, they don't get a lot of money for UI designers so frequently, they look very plain... CHUCK: Twitter Bootstrap? [Laughter] DEBORAH: Or, they look very much the same as all of the other ones using just Bootstrap. JOHN: I think Twitter Bootstrap needed an upgrade sometime, from what I see. CHUCK: [Laughs] DEBORAH: Exactly. Exactly. And again, there has been talk recently about changing this kind of environment so that people would start thinking of these software development units more as productivity-centers because they are improving the productivity of the entire office. But in most management structures, they're still considered to be cost-centers and they are working on cutting costs and not wanting to spend extra money on themes, or a design, or any of that; they mostly just want to get it done. I think, one of the other things that really distinguishes the Line of Business application developer from a lot of these developers who are working at companies that do software as a business is that they frequently have a much broader set of things that they have to do. They have to manage office and do the office apps in addition to any old access 2007 apps that they still have to maintain in addition to VB apps from 2003 that they're still maintaining. So they are frequently required to have in their toolbox a huge amount of ability to quickly go in and update apps that might not have been brought up to date and are really old so they have to know all of these different technologies and being able to do all of this really quickly because there are 8 more departments behind wanting their little fixes done or whatever. WARD: Yeah. And they often have to deal with Legacy Data... DEBORAH: Right. WARD: They'd almost created some place else, they sometimes get to start from scratch, but they usually don't. They're not lying eyes for their great user experience because that doesn't seem... that it's hard to even get them to think about that. They are concentrating a lot on gathering user input from end-users, right? I mean, like if you think about a Twitter app, there's a box you should type in and then you're done, the FunBox [chuckles], and they display a lot, right? Whereas my experience with LOB apps, tell me yours is that they often a lot of Forms over data, isn't that right? DEBORAH: Yes. And a lot of times, that sounds somewhat simple; you're just going to have a Form, you're going to have some data, you're going to display it. But most companies have just amazingly complicated business rules that they're trying to put in there. Like, I've done work with insurance companies and the massive quantities of rules that "you can't do this if you're doing that", or "if you buy this, you can't buy that", or "if you buy these 2 things and it's a different price, if you buy those two things with the third thing, then it's different". It has very complicated and extensive business rules, and those rules also change from time to time because of tax laws or government or they just bought the company down the road so now they're trying to implement all of their rules as well. So, there's a lot of change that's happening and these poor Line of Business application developers are supposed to be reacting to these things and trying to get things done really quickly. Even a testing side of the house can be significantly different. I worked with one medium-sized company who was completely against spending any money for testing; any kind of unit testing, any kind of developer testing. Because all the software were just going to be used by their internal users, they can be the testers so why spend any money at all doing any testing? It was the most absurd thing I've ever heard [laughs]. WARD: Yeah, but you do run in to that. DEBORAH: You do. WARD: And if you say the business rules, and also the business models, there sure are variety of things you can make rules about because you've got these big volume of orders, details, products, categories, levels. If you drew the graph of the interaction of the different components or sort of domain objects that are in there, it's really quite extensive. And again, if you look back at the products that are developed for consumers, they internally don't have -- because they're over facing -- they don't have complex business rules. What's the business rule for a Twitter box, right? And, they don't have rich data models either, in which they're expecting the consumer to type into it because you can ask the user to type, the consumer user, to type in a whole lot of stuff. DEBORAH: Right. WARD: So I think that yeah, it's a completely different set. And, they're also on a real time pressure to deliver features, aren't they? DEBORAH: Yes. WARD: So they put a lot of value on ease of development. There's a real high premium on the LOB space on how quickly you can develop and deliver a change or the original stuff, right? JOE: Oh, yeah. The idea of release when it's done, or when it's right, that never comes up; that's a luxury you don't ever get in Line of Business applications. DEBORAH: That's correct. JOHN: We want you to finish it on time along with everything else you're doing. Everything is priority number 1, and high quality. WARD: [Laughs] JOHN: And by the way, there's no time after you deliver to actually fix everything with technical depth. CHUCK: That's freelancing. DEBORAH: Yeah. And in addition to all of that, you're expected to do the corporate meeting where we're going to discuss what new phone that we're going to be giving everyone [laughs]. WARD: Right. CHUCK: I'm wondering, do they tend to have a steeper learning curve than other developers? Or, is it about the same, or is just different? Because it seems like there'd be a whole lot more just business domain knowledge that you'd have to know in order to provide for your particular company and the way that they do things as opposed to being a developer that sure maybe specialized to a particular community, but mostly can just work in the market. DEBORAH: Yeah, it's really hard to generalize about any group of people. But I would say in general, you'll see a lot of Line of Business application developers have to be significantly broader because they have to know Access, and Sequel Server, and Oracle, and the Office, and all of these different environments that they have to maintain products for so they frequently can't get as deep in any one of them. Like, if your job was developing Twitter, that's all you would do all day everyday and you would know those tools inside and out and you would have some of those luxuries, but frequently, you end up not having the time to really dive deeply into any one tool. And again, that's kind of a generalization. There are some companies, though, that have tried to focus on a specific set of tools. I recently spoke to a couple of software developers at a conference I was speaking at, and they said that they set up a complete architecture and entire set of internal tools, libraries, techniques, and everything that they couldn't possibly think of around the development of very, very quickly building Web Forms applications. So they could go get requirements from a department that needed a new something and they could use all of these tools and pre-build pieces and everything and very quickly come up with a Web Forms app. Then, they come to my talk on Angular and they go, "Okay, what do we do? [Laughs] Do we keep going with this whole Web Forms thing that we have because we have all of the pieces and the techniques and our development team is knowledgeable on how to put these things together quickly? Or, do we change paths and what's the risk with that? And, how do you possibly explain to a non-technical manager why you would want to give up all of this background that you prepared to make life easier to go down this new path?" WARD: Well, does make it easier? This is a great segue into the whole Angular and SPA world. What are the forces that you're seeing that are driving people to bend in the comfort of Web Forms and go to say, an Angular type app, in order to deliver the same kind of LOB app? What are you seeing there? DEBORAH: Well, some of the key benefits that people are saying with Angular is, it's data-binding so that you can very easily do forms over data. It has all of the validations that you can very easily do all those business rule validation things that you need to do. With 1.3, they made custom validation and async validation so much easier so there is a lot that you can do now very easily, but it's just a big step over and then redoing what you had done in terms of getting everyone trained on your whole development team, trained on how to use the tools and what your new UI layouts are going to look like, and so on. CHUCK: Just to clarify really quickly, you've used the term "forms over data" a couple of times. Does that actually have a particular meaning to you because I'm not sure what you mean by it. DEBORAH: I usually think of forms over data as an application that primarily is either displaying information to the user or requesting information from the user. CHUCK: Okay. DEBORAH: So it's not doing something, like Twitter has got all those things to show you all the tweets and to sort all those tweets. But when you're talking about Line of Business applications, you've got big forms with 50 different data entry fields on them that the user has to fill out or update or whatever, so it's a lot more data entry and data display. WARD: And a lot more of those either tab interfaces where you're drilling in the things and then entering some more data or navigating from page to page to find a new set of some things that typed into, right? DEBORAH: Yup! JOHN: One of the things I'm curious about is, we're talking about Line of Business application, so a lot of the developers who work in business and enterprises these days, Angular is still relatively new to them. And if you go back a year, most of them is pretty new, too. Lot of them are even working with things like Java, or WPF, or Silverlight, .NET, or ASP.NET, PHP. What I'm noticing from those is, when they're introduced to Angular, SPA, JavaScript world, Gulp, Grunt, npm, Bower, all these different terms, these are very, very sharp developers who are instantly immersed into 10 new things or more that they have to learn. Are you seeing that, Deborah? And when you do, how are you helping them get there? Or, what are those challenges that you find that are easy to overcome in that space? DEBORAH: Well, one of the things that's really nice that has helped some teams that I've worked with moved to Angular easily is that the way that Visual Studio is set up is if you're on Microsoft shop and you already know Visual Studio and you're a Line of Business developer who has used Web Forms, or WPF or, heaven forbid, Silverlight, and now you want to move to Angular, your Tools can still be the same. You don't have to learn npm, you don't have to learn Gulp or Grunt, or Transpilers, or Loaders, or you don't have to learn any of that stuff. Because of some of the work that you've done, John, and Microsoft has done, you can just go to the NuGet package manager and say, "I want Angular," you can say, "I want bootstrap," you can say, "I want Angular routing," you can say, "I want resource management in order to talk to the database," and it just comes down and works just like Web Forms and Windows Forms and anything else that you might have done in Visual Studio. So, that's been really nice in terms of providing a real easy path for people already knowledgeable in Visual Studio to move over from something else into Angular because it's still the same Tool and it's still the same intellisense and the same techniques and such. CHUCK: I grew up outside of the Microsoft world, what is NuGet? DEBORAH: NuGet is a Tool inside Visual Studio that you just go to your project and say, "Manage NuGet package as," and then you can search online and pick anything that you want to download and it automatically downloads it from wherever (you don't have to know where) and it puts it into your project so that it's actually all right there, all of the code that you need. You don't need to know where to get Angular or where to get Bootstrap or where to get any of the other libraries that you might want to use because they've all been packaged up and are ready to go. So, it's basically the package manager that's provided inside Visual Studio. CHUCK: So it's like npm except that it has a UI component that extends Visual Studio? JOHN: Yeah, there's a command-line tool for that, Charles. CHUCK: Okay. JOHN: So what happens is NuGet existed for a long, long time and originally, it's mostly user things like DLLs and other packages that you could pull down. But as the web started to unfold and things, again, Bower over there, it was less, I'm going to say there was less sure of who is going to be the leading package manager out there. People started throwing in JavaScript libraries like Angular, such as me, into NuGet to have another way to get Angular into your Microsoft application. So, NuGet became a place where you can get anything you wanted. But now, where Microsoft is heading is NuGet is great for DLLs or [incomprehensible] files or with Maven. But if you want to get web components, that's really left to npm or Bower and the best tool for the best job. WARD: I think that the, as in some Deborah's point is that, Visual Studio provides a comfortable, familiar environment in which you can graphically (through point and click) get a lot of your work done. Drag-drop, get a lot of visual feedback, you never have to leave the friendly confines of Visual Studio to get the job done. You don't have to drop down to a command-line and try to remember what those commands are and type them in, and you can reach in one place for all of the different technologies that you need and bring them together so that it'll all feels like one comfortable, helpful environment. Microsoft has done a great job over the years of creating that, all encompassing friendly environment and that LOB developers count on in order to be able to cover the ground they have to cover. Isn't that pretty much what you're driving at there, Deborah? DEBORAH: That was very eloquently said, thank you, Ward. WARD: Of course, the wheels are coming off that these days, but that's certainly what they traditionally provided to make it good for the LOB developer. DEBORAH: Yes -- WARD: And they still, though, they still though -- and I love if you can comment about this -- they do all that and that certainly makes it easier for them to sort of take on a new technology such as HTML or JavaScript on the front end and Angular in particular, but it ain't Web Forms. Web Forms was a nice drag, visually drag the component on to the screen and write some C# in the back, the code behind, and go. Are you able to help the Angular developer get to the point where they're almost as productive as that? DEBORAH: I've been training a lot of newbies, so I've been doing a lot of Angular 101 style classes. I'm doing another one at the upcoming AngularU Conference next week. But what I'm seeing people say in those situations is that, it's very clear to them what they are needing to do even if they came from a Web Forms environment that they feel, because of the fact that Angular has the smaller HTML fragments and the way that it's put together and modularized that puts the application in bite-size pieces and they're feeling relatively comfortable with that, it's not appearing that scary to them. But there still has a lot of feeling from a lot of these developers that if you have to go to the command-line, something is absolutely wrong. You're doing something wrong if you have to go to the command-line to type something in because everything you need should be somewhere in Visual Studio. WARD: Yeah, yeah. Which features of Angular, which is like the top 3 features of Angular most important to LOB developers? DEBORAH: I would say that data-binding is one of the key ones. WARD: One way? Or, two-way? DEBORAH: Two-way, absolutely, because there's so many data entry forms that they have to deal with. JOE: Uh-oh! You're feeding Ward. WARD: I know. [Laughter] WARD: That was like, "just one of that bring-that-forward... Go ahead, Deborah, tell them the truth!" JOE: [Laughs] DEBORAH: Now I really forget what the other two there that I was going to say... So one of them is... JOHN: That's why there is. But, [Incomprehensible]. WARD: [Laughs] Oh, you guys are terrible! [Overlapping of voices] DEBORAH: No. The marginalization so that your controllers are very clean little bits of codes so you're not telling them that they need to write 200 line JavaScript files, you just have to write that little bit of JavaScript and then you can do the rest in Services. And I think that organization helps them picture how it's going to fit together and it's not quite as scary as looking at some of the pure JavaScript, JQuery sample apps where you have some big long page of complex looking JavaScript. Those are the 2 main ones. And then things like routing is very helpful as well so that you could do a nice tab-based UI and use UI router to have routing within routing to do the tab-based pieces and so on. WARD: Are people writing custom Directives? Or, is that something they just don't need? DEBORAH: I found that a lot of people don't initially do that, but at some point, they find functionality that they want to repeat. One of the common ones is, there's so much code involved with validation and when to be nice to do a custom Directive that would help with some of that validation and that kind of thing. But in our 101 courses, we don't even show them how to do that. WARD: One of the things that appears a lot in LOB apps, in my experience, are Grids, sometimes even editable grids. What are you recommending that people do? Or, how are they coping with that in the Angular space? DEBORAH: It's an interesting question because I did a Pluralsight course called "Angular Line of Business Applications". In that course, I had an entire module on working with Grids because Grids are so commonly used in Line of Business Applications. I got it all working and it was great. I went to record it. The Grid that I used was being completely rewritten in the version that I had downloaded. It didn't work at all with the one that I had and completely didn't work so that whole module got tossed. I understand that, now, which is almost 8 months later [chuckles] that the new Grid is now operational again and is now called ng-grid instead of UI Grid, but I have not yet gone back to try it. How's that for a long answer to a short question. JOHN: Let me ask a little on some Grids, though. I mean, Ward, you're talking about them, Deborah, you're talking about them, I've used them recently. Grids are always that big staple of LOB. I've done my personal pick on this and I feel like the Grids that are out there, none of them are great; they all suffer problems. But, this isn't a unique thing to Angular. We had these issues with .NET and other technologies, too. Are we asking the wrong question with Grids, though, when people need them? Meaning, our people using the wrong controls to solve the problem, me asking another way, would you put a Grid on the phone? WARD: Well, now you're going to be getting into a fist fight with me on that one because I don't think of an LOB app that's belonging on a phone. I mean, Deborah, the tip commodality is the browser, right? DEBORAH: Yeah, because, again, most Line of Business Applications are asking the user to enter 50 bits of data; there's no way that you would want to try it and do that on a phone because the price of the product, and the caller options, and whatever, it's just got huge amounts of bits of information. Or, for any particular insurance policy, there is tons amount of typing involved and you wouldn't want to do that on a phone. JOHN: Okay. So, we're specifically talking about Line of Business, you mean bit apps that are sit down at the desktop computer as opposed to apps that could be used by a business. So, just the ones where you're actually entering data. DEBORAH: Usually, there are also the "Management Apps", and those could potentially be on a phone. And then, those wouldn't have Grids for data entry because those would be more of the manager's summary. So a manager would be able to come up and say, "Okay, how may widgets do we currently have in inventory?" Or, "How many widgets have each of our sales people sold this week?" that they would want to get summary kinds of information. And that would also be considered a Line of Business Application, but it's more the management console kind of an app as opposed to Forms over data kind of app. JOHN: I guess this is where I'll disagree a little. I think, there's definitely a place for a Grid and things like that and sit down on the desk and do it on the laptop or desktop. But I also believe there's a great place for business apps to be using phone and iPad and other devices as well with entering data. And I don't mean entering Grid data. God know, please know. But I guess what I was heading more towards, and I'd like to hear your opinion is, I get asked a lot about, "Hey, John, what do you think about this application in the screen? I've got 22 tabs on it, each tab has a Grid, each Grid has a grouping which has a tree View nested inside of it, which has got a part which should appear in the tree inside of that." My first concern there is, what the heck are we actually trying to accomplish? Is that a good thing to do in a business app? Are we still seeing this everywhere? Or, it might be the other one who sees this stuff [chuckles]. DEBORAH: Yeah, and I think part of that is that you start with some little prototype that you did to show how the user might enter data in one tab, and suddenly, 4 years later, it has those 12 tabs and 6 trees and whatever, these things tend to grow uncontrollably. So, instead of a nice tree with beautiful branches that gets shove in any direction that it needs to go in order to get things done quickly, I think you see (Russian stacking dolls) you do see quite a bit of that. Though, I think that in general, developers try not to do that, but frequently, that isn't what they started out with [chuckles] and it isn't how it started looking at the beginning. And I completely agree that throwing that much information at the user isn't necessarily helping them accomplish what they need. Frequently, it is a good idea to step back and say, "Okay, sometimes a person of a certain type needs this kind of information and they, maybe, when they login, should see it differently than a different person who needs the information differently instead of trying to meet all the users' needs in one big UI. WARD: I think the control vendor is drove that one when they were competing with each other. They would just add a new feature and somebody would say, "Ooh, look what I can do. I can do a Grid inside a Grid," and it induced people to solve problems that way. But if you cut off that extreme, there is just an awful lot of LOB style problems that lend themselves to the Grid as Excel itself, spreadsheet as my proof. JOHN: Would you agree, Ward and Deborah, that the most common scenario for Grids that I see is really [incomprehensible]. The people need to show tabular data in some way (rows and columns), they need to be able to page or divert your scrolling, so lots of data (maybe 10,000 rows, but not all at once), they need to sort, filter, and sometimes at it in the line. To me, those are the most common features in a business application when you've got lots of data entry. It's not the tree view inside the Russian stacking doll. WARD: Right. I totally agree with that. And Deborah, that would fit the 90% of the case that you say, too, right? DEBORAH: Yup. WARD: But what we don't know, as Deborah's sort of tale played out, is that I think that even that set of functionality is under served at the Angular or the SPA space, at least as far as I know, because I can't put my finger on the Grid that I would recommend to people who let fits just that scenario. I don't know if any of you guys have something, but I don't have one. DEBORAH: Well, the UI Bootstrap just came out with a new Grid, which used to be called "UI Grid" and is now ng-grid. I haven't looked at that, have you looked at that one? WARD: No, I haven't, I confess. DEBORAH: I haven't either so I don't know what it looks like at this point. But it might be something, if someone is interested in doing a tab-based UI, it might be something, at least, worth taking a look at. WARD: Well, I don't want to get too hung up on this one because we're drowning in it. But I do think that it reveals to something interesting about the direction of these libraries, which is like Angular. But what are the others, too, is the people who are inventing them and leading them are often thinking about a different kind of developer with a different set of problems than the LOB developer faces. I don't know if you'll agree, but I think that there are more LOB developers in this world than there are developers of any other kind [laughs] who actually get paid for it. And yet, it seems as if these library designs are not quite catering to them. DEBORAH: Yeah. And I think one of the problems with being a Line of Business developer is that frequently, they are not seen because of the fact that they're seen as cost-centers, they frequently don't have the budget to be the ones that are out of the conferences, they don't have the budgets to be the ones that are out there doing public kinds of activities so that their voices are necessarily heard. And their time is so short that they're not on Stack Overflow, at least not answering; they might be using it a lot for gleaning information, but they're just so short on time with everything. And so I think that they are almost like that silent majority that you just don't hear from them all that often because they're just so darn busy. JOHN: Yes. Scott Hanselman calls them "Dark Matter Developers", which is not a negative term. It's the term of "we all know they exist, but we don't normally see them". To be fair, we all frequent these conferences and speaking sessions, some of them come to them always, but there's a lot of developers who never get out and interact with some in their areas because they're deeply nested in their own environments, and that's because that's their job. So, learning some of these newer things and work with Angular, I think there's a learning curve in some cases and trying to apply what your business needs, to those this is important. And I find it often that one of the big things in software is things like Performance. So having a data Grid or having a large data entry form, and having a thousand data-bindings on the screen, how do you handle those kinds of things when you're working with some of your customers in these apps, Deborah? DEBORAH: One of the things that people fall into with doing Angular is Angular has all of that client-side scripting or client side filtering rather. So you can bring all the data down and then you can filter it down. But when you have thousands of rows, you don't want to do that, and they don't necessarily show in any kind of introductory Angular conference or Angular session how you deal with that. So one of the things that I've been trying to talk about is doing like OData so that you can use OData to do server-side paging and to do server-side querying. So the user would type in some query string and it wouldn't bring down all of the data and then query on the client, but rather it would do that on the server. I've been trying to talk about using OData with Angular so that people know that there is another alternative to using the client-side filtering and the whole play would improve a little bit, some of the performance issues that they could otherwise run into. I think the one big thing that is most scary to many of these Line of Business applications, especially those looking at Angular right now, is where Angular is going. WARD: Yeah. You want to talk a little bit about that? And it isn't just limited to where Angular is going, it's like where Microsoft is going with this Tooling, too, right? DEBORAH: Right. As we mentioned before, one of the really nice things about Angular 1.x right now is that you can go into Visual Studio, like Visual Studio 2013, and you can do it using all the same tools and techniques. Now, with Visual Studio 2015, they're changing that up a little bit. Visual Studio Code requires a huge amount of work on the developer side to make it all work, and some of these other tools. And you look at Angular 2 and you look at Aurelia -- I never know how to say that. Is that Aurelia? [chuckles] -- and you look at these other packages coming down the road. I started reading about Aurelia and the first thing it says, "You have to download npm, and then you have to download this Transpiler, and you have to download this Loader, and then you have to download this and the other thing," so 8 things later, you finally have something that you can then start to do a whole new world app with. And I think that that's all scary because, again, these developers are looking at, "Oh my gosh! I have such a short amount of time. I don't have money for a huge amount of training. How am I going to learn npm, Bower, Grunt, Transpilers, Loaders, on and on and on and still get work done?" I think that there's a lot of fear right now as to where that were going or becoming a development society that is all on the command-line. I think that there's a lot of fear about that. WARD: Yeah, I think you're right about that, much as some of us who have the luxury of learning all of that are taking a certain degree and the light in being able to have all these options. It has to be terrifying to anybody who's used to Visual-Studio-all-in-one-place world. My sense is -- and I agree with you that the current look of the direction of the Visual Studio 2015, the whole ASP.NET 5 movement does sort of give you this big jump box with all the tarps and pieces; that's got to be scary to people, too. You think? DEBORAH: I do think, yes. WARD: So on the bright side of that, Mads Kris... Have I got the right Mads? JOHN: Hans Christian Andersen. WARD: That [laughs]. He's been trying to show the kinds of direction that they've been doing in Visual Studio that would, again, create the kind of comfort in Visual Tooling that would paper over all that knowledge of npm and Bower and make it a little bit easier. JOHN: Yeah! And it's really interesting, Ward, because -- and to get his name right, Mads Kristensen is good friend of ours, he's doing great Tooling in Visual Studio and they've been enhancing the ability to basically make it an easier experience like sugar on top of npm and Gulp and things like that, but they're also adding an experience where it's more just a point and click if you want to do your own kind of bundling and minification and things like that, too. So I think, as Deborah had pointed out in Visual Studio side of the world, they're trying to make it easier for those who've never gone to this command-line world to stay where they are and still get a good experience, but also make it such that maybe we can let you use these command-line things direct from the Tool that you know and love. So, they're trying to cater to the audience. I don't know how effective it will be, but it's interesting. WARD: I think they're all in on trying to do, and that's the Microsoft's acknowledged drink. Like, people who like Microsoft or don't, they do admit that Microsoft has always been strong at building these kinds of tools, these point and click tools. So I think that it's absolutely, if you say, Deborah, right at the moment, it's a giant mess for anybody who's coming to it from that. But Microsoft is working pretty fast in Visual Studio to try and return to that comforting Visual programming experience. Not with VSCode; VSCode, let's be clear, I totally agree that they experts tool that's not for the LOB developers as far as I can tell. But Visual Studio, they seem to be doing it. DEBORAH: Yeah, with code, you can even just run. So if you write an Angular app in Visual Studio, you can just run it. If you write an Angular app in WebStorm, you can just run it. If you write an Angular app in Visual Studio Code, you can't run it. JOHN: What do you mean by that, Deborah? DEBORAH: You have to actually create a web server to run it with. So you've got to go to the command-line and type in some lines of code in order to tell it that you want to launch a web server in order to run your pages. Where if you bring up WebStorm, you just click on the little icon that you want to bring it up and IE or whatever browser that you want to use and it just comes up, it just runs. You can't do that in Visual Studio Code. JOHN: Right, because WebStorm and Visual Studio are using a built-in simple web server that you can use. Whereas in VSCode, you could go to the command-line and type HTTP server and run one, but [inaudible] you have to do. DEBORAH: Exactly. That's exactly right. WARD: And you can run tests natively in Visual Studio. If you have Test, you can debug natively in Visual Studio if you wanted to do that, if you thought that was the right place to do it. [Overlapping of voices] WARD: I think that some of us might say, "That's not the best way. We don't think that's the best way to do it, but we got to tip our hat to the fact that for LOB developers who are trying to master one thing at a time and have some of the other pressures on them, they're making some sense with the way they're trying to attack it. JOHN: I think there's a lot of room for Tooling improvements. You have to have the right things in place if you have Tooling; it's always been this way, right? You don't build the Tool before you know what you're going to tool around. So I think there's a lot of value in these IDEs like WebStorm and Visual Studio to be able to provide that experience while there's also "Why don't you get on that road and understand how these things are working,", there's also a lot of room to be using these Editors, which are like "Let the Tools get out of my way and let me code faster". So for the LOB audience we're talking about, though, I think the perfect starting transition point is the Tool like WebStorm or Visual Studio. DEBORAH: I agree. WARD: John, I agree with you. DEBORAH: Yup. JOHN: That same sense, I have to call out that I don't think it's a good idea to completely ignore that command-line is there. WARD: Yeah. I think we're in agreement there because the way that Microsoft used to do it is they lock that all behind closed doors. And if you try to get behind those closed doors, it was completely proprietary and hard to figure out [incomprehensible] stuff. Now what they're saying is, "No, we're going to use what the rest of the world uses, we're just going to provide a Tooling surface over, if that makes it feel comfortable. But whenever you want to park the curtains and see what's in there, you're actually getting it, you could do it, and you can get at something that the rest of the world would recognize." That's a big switch for them. So, Deborah, there's this Angular 2 thing hanging up in the world there, if you're talking to business developers and they're asking you, "Yeah, Deborah, there's this new thing out there called Angular 2, should I use that?" what would you say? DEBORAH: I have been recommending to people that they want to keep an eye on what's going on with Angular 2, but definitely not to go there. The other thing that I have been recommending to people, especially people coming to Angular from a Class-based object toward to programming language like C# or Java, is to take a look at TypeScript because I think if you did your Angular app, your Angular 1.x app today with TypeScript, that it will be a much easier path to Angular 2 in the future. CHUCK: That sounds really familiar. WARD: It does sound familiar! CHUCK: [Laughs] DEBORAH: Is that what you guys have been recommending already? WARD: No, no. We're hearing that from a number of our guests, and it's curious that you brought that up without our prompting. CHUCK: Yeah, we had a long discussion and basically came to a very similar conclusion last week, too. JOHN: So let's play those app git, though. Deborah, with you not being in the discussion, why do you feel that that's an important way for them to go? DEBORAH: A lot of what you're saying in Angular 2, especially in terms of examples and such, are all using TypeScript, so I think that that's really useful. More importantly, though, for the Line of Business application is something that were brought up earlier, and that is frequently with Line of Business applications, you've got rich object models. And if you are used to coding those object models in C# by building Classes with Properties and Methods using TypeScript and being able to create Classes and Interfaces and defining Properties and Methods, it's going to feel much more natural. WARD: Then I can get Intellisense. DEBORAH: Yes, you do. JOHN: And for the complete type checking and... WARD: Some form of Refactoring, a relatively safe Refactoring, which is like deadly in regular JavaScript. JOHN: So, will those things help you avoid issues like 4000 lines of JavaScript inside of a controller? WARD: [Laughing on the background] DEBORAH: One would hope so, but no Tool would prevent developer from creating bad code if the developer has spent time creating bad code [laughs]. JOHN: Yeah, I know. I threw an easy one there, but yeah [chuckles], I see that still. DEBORAH: Yeah. And if I can just mention, the course that I'm working on right now for Pluralsight is called "Angular with TypeScript". CHUCK: Oh, cool! I know some guys that did a TypeScript course. JOHN: Yeah! DEBORAH: Yes. And it's kind of a follow on to that, but specifically aimed at, "Okay, now that you've watched this course and have the basics of doing TypeScript, how do you actually build a good Controller, how do you build the Service, how do you put all the pieces together, specifically for Angular. JOHN: Yeah! And I know, we, you and I have spoke, Deborah, about how VSCode, and Angular, and TypeScript form work together, we can talk maybe in another session on the show. But, I think it's a very interesting paradigm to see not only if you want to do Angular 2 with TypeScript but how do you use it today with TypeScripts and get a good Tooling experience. CHUCK: Alright, let's go ahead and get into picks. Joe, do you have some picks for us? JOE: Yes, I do, Chuck. Yes, I do. I'm going to pick a game this week, as I frequently do. I do like board games, so I recently played a board game called "Camel Up". I actually purchased a copy of that while I was in Denmark and brought here. All the instructions are in Danish, which works very excellently, but you can easily purchase it here and get the instructions in your native language. Whatever here maybe, probably, accomplishable. Its a really fun game. It has a lof of depths to it, but it's also works very easy. You're betting on camel races, so if you got kids, you want to play with kids. It's great because they really had a lot of fun with the camels moving around and rolling dice to get the camels moving. The camels actually like leap each other in the game. It is really fun for kids and for an older adults, more sophisticated crowd. You're betting on the camel races and trying to calculate the odds as to when to bet and how much to bet. And you don't just make any bet that you want, you have preset bets you have to take. It can be pretty interesting to choose when and how you're going to bet. I played it a couple of times with some friends just last night, we had a great time. So, that's going to be my pick. It's the board game Camel Up. CHUCK: Alright. Lukas, what are your picks? LUKAS: Based on our podcast from last week and talking about the state of the world in JavaScript, I've been looking into ES6 and trying to learn that. There's a book "Exploring ES6" by Alex Rauschmayer, I believe. There's actually a free version online. I'm going to go ahead and purchase the print version of the eBook version. Very good, reads really well, and I think it's never too soon to start learning ES6 in TypeScript. CHUCK: Nice! DEBORAH: Can I ask a question about that? I heard a rumor that they're changing the name from ES6 to ES 2015, is that true? JOE: We refuse to acknowledge that. LUKAS: Yeah. I'm going to fight it. JOE: Anybody besides the people on the TC39, I'm refusing to acknowledge this name change, but that's true. And ES7 is JavaScript 2016. WARD: The point of it is to try and get to yearly releases of JavaScript rather than to wait 8 years, which is I think how long it has taken ES6 to come up. JOE: Yeah, and they'll just release whatever happens to be ready and label it with the year, it's the idea there. WARD: We'll see if they can execute. DEBORAH: [Chuckles] CHUCK: Yup. So it's true everywhere but here, yes. WARD: As a matter of fact, I don't know anybody who is actually vocalized that as ECMAScript 2015. It's a mouthful, isn't it? CHUCK: Yup. DEBORAH: Yes, it's so much easier to say ES6. WARD: [Laughs]. JOE: And I think it's not ECMAScript 2015, isn't it JavaScript 2015? WARD: Oh, I've missed that. CHUCK: Oh! I've only heard ES. It's ECMAScript... JOE: Well, anyway, whatever it is, it's stupid. [Laughter] CHUCK: Alright, Ward, do you have some picks for us? WARD: I do. This month of June, one of the world’s greatest font designers Herman Zapf died. I don't know how many people are into Typefaces out there, but he invented a lot of them and wizard of genius at it. I think the Vietnam War Memorial was done in one of his Typefaces , I can't remember. Anyway, fascinating guy, and I'm going to put in a link to a 1960's video of him because he was doing calligraphy as well. And just to watch the ark of Typeface design and how he talks about it is fascinating. He's one of the characters that appears in the book that I very much like called "Just My Type", which is a book about Typefaces by Simon Garfield. So if you're ever feeling like stepping away from the programming, from the code and trying to think about that beautiful type that appears on your screen from time to time and how it comes to be that way, I recommend Just My Type and I recommend that you look into the life of Herman Zapf. CHUCK: Cool! I'm going to pick a book. I just started reading it, it's called "Essentialism". I'm really enjoying it. Basically what it is it's about getting down to the basic stuff that get you what you want and saying no with all the other stuff (I'm not really good at that). The book is really helping me formulate a lot of that stuff. So, I'm going to pick Essentialism by Greg McKeown. LUKAS: I checked on that actually. I just read that a few weeks ago, and it is amazing, very good book. CHUCK: Awesome. Alright, Deborah, what are your picks? DEBORAH: I mostly wanted to just provide a link for Angular 1.4. Angular 1.4 was just released May 27th, and I know that it was a couple of weeks ago already, but I thought it was important for people to know that they still are, even though they are working on Angular 2, that they still are doing improvements to Angular 1.4. And I also wanted to just note that the Router that was promised in 1.3 and then in 1.4 still has not made it. So Angular 1.4 sends the new router, is out and available. JOE: New router that's supposed to be out in 1.3? DEBORAH: Correct. Didn't make 1.4 either [laughs]. 1.5 maybe. WARD: I just hoped until a little bit, is 1.4 official because I go to the Angular as we talk today, this last stable version on their website is still says 1.3.x. JOE: And in front of code.angularjs.org, you can... WARD: I'm going at the wrong place, huh? JOE: No, if you just go on the front page, I guess it takes some time to update. But code.angularjs.org is code drops work and it's also their CBN, and you can just scroll... WARD: Right. And that lists all the versions. But how do I know... Oh, there it is! 1.4.1 doesn't have an RC on it, you're right! JOE: Oh, there's 1.4.1 RA? Oh, wow! DEBORAH: Yup, that came out yesterday. WARD: That's the only one that doesn't have an RC on it. I'm putting a link right into the show notes. JOE: There's 1.4.0 that doesn't have an RC on it. WARD: I'm staring right at it, I'm missing that John. JOE: Oh. DEBORAH: It's up above all the betas in the RC, right below the 1.3.9. JOE: Yup, yup. WARD: [Inaudible] JOE: Because alphabetically, it's before stuff with beta even though release-wise, it's after. WARD: There you go. Well, anyway, news to me! So there it is, it's out. Well, 1.4.1 is the current [laughs]. CHUCK: Well, there we go. Deborah, if people want to follow up with you or see what you're working on, find your Pluralsight courses, what are the best ways to do that? DEBORAH: I can give you both my email address and my Twitter handle. JOE: Do you want a podcast to your email address? CHUCK: Email address, that's brave. JOE: [Laughs] All the listeners, there's... LUKAS: All the fan mail. JOE: There's like 5000 listeners, so cool with that. Go right ahead. CHUCK: Alright! Well, thank you for coming. It's been a really interesting discussion. JOE: Thanks for coming, Deborah. WARD: Thank you so much for coming on our show. DEBORAH: Yeah, thank you very much for having me! CHUCK: Alright, let's wrap this up, and we'll catch everybody 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!]**
