On this episode of Eat Sleep Code, Brian and Ed cover the latest news in the development community including: bots-bots-bots, React setup, ASP.NET Core RC2, Project.json, and NativeScript.
The Telerik Developer Digest is the latest collection of the best articles from the Telerik Developer Network and around the web, curated by a group of Telerik developers just like you.
Ed Charbeneau is a web enthusiast, speaker, writer, design admirer, and Developer Advocate for Telerik. He has designed and developed web based applications for business, manufacturing, systems integration as well as customer facing websites. Ed enjoys geeking out to cool new tech, brainstorming about future technology, and admiring great design.
Brian Rinaldi is the Developer Programs Manager at Telerik focused on ensuring that the Developer Relations team creates top notch content for the web development community on the Telerik Developer Network..
E: Hello and welcome to Eat Sleep Code, the official Telerik podcast. I’m your host, Ed Charbeneau, and with me today is my co-host, Brian Rinaldi. Brian, how’s it going?
B: Hello, it’s going great.
E: And today’s another Developer Digest episode, and we have some great articles that we collected from the web to share with you guys, and we post those on our Telerik Developer Network, and we’re gonna give you our commentary on those and then you’re welcome to go find those on our website, and read them or sign up for the newsletter. So, let’s kick things off with our first article by the always amazing Jen Looper. And she’s got an article called bots! bots! bots! And it’s pretty much about bots. So, like Microsoft, and Google, and Facebook, at their big keynotes this year, have all come out with their own bot frameworks. And it seems like 2016 is the year of the bot, right?
B: Absolutely, in fact, I talked to somebody… This was a PhoneGap Day earlier in the year. They were telling me before things had really taken off, they were like, “Bots are gonna be the thing.” I guess they were right. So, it just really seems like it’s taken off. Every company is releasing a bot platform, people are writing bots left and right. I think it’s really cool. I think the reason probably is it’s easy to interact with. It’s just natural to interact with a bot if it’s done well, right?
E: Yeah. In my opinion, I think some of the relativeness of bots and why they’re kind of making a comeback, and I say making a comeback, ’cause we’ve had bots in other chat platforms for years, but those things were always command driven, right? You always had to slash some command and then some parameters for that command and the bot may throw an emoji out or something. But now, we’ve got this machine learning from all the big software manufactures and it’s a lot easier to parse through natural language and figure out what people are talking about, what they’re discussing, and less reliance on the specific keywords to make a bot do something. You can kind of glean what the conversation’s about or what the question was, and the big companies like Microsoft, Google and Facebook, are making APIs to help facilitate that stuff.
B: Yeah, totally. And on that note, all of this blends together with not just bots that you type to, but also ones you speak to. Things like Amazon Echo or Google have their Google… I forgot what they called their one that they released at I/O, or announced there anyway [editor’s note: Google Home]. So, I actually have an article coming up about writing for the Echo. In that case, the commands are spoken. In the end, there’s really not a lot of difference because the commands are spoken but then translated into text that I then parse and respond to. And then I send back text and that text is just spoken. So, it’s effectively the same kind of thing as these bots, but I think you’ve noticed companies starting to add those voice assistants into just about every device that they have, and people like to use them. So, it’s one of those things that I’m always kind of skeptical of the next big thing, like wearables and VR and things like that. I’m a little skeptical that those are really gonna be quick to catch on. Wearables is obviously a market but it’s somewhat small. And VR still hasn’t proven that it’s necessarily useful to me. But this one, I think it’s so simple to interact with, and the ability to either just naturally type or naturally speak makes it just a no brainer.
E: Yeah, my only concern is that some of the demos I’ve seen have shown bots interacting with other bots to get things done. You’re like, “Cortana or Google, I wanna hotel room,” and then, the hotel picks up with its bot and it’s like, “Oh, I have 5 rooms available,” and the bot tries to negotiate with the other bot. And you already can’t get a human being on a phone or any other means, and now we’re gonna have bots interacting with other bots. It’s like, how far removed are we gonna get when there’s a problem the bots can’t solve?
B: But that’s an interesting idea. I hadn’t really thought of that ’cause effectively a bot is an API, in a way, that I can interact with with just text. You could actually have a bot call a bot as if it were an API.
E: “I’ve been on the phone for five hours with your bot. I need to talk to a human being please.” [chuckle] Alright. So, Jen wrote a great article anyway on how to create your own Slack bot, and she walks you through setting up the SDK and setting up the environment there and creating a test, scripting and deploying. She actually used Modulus which is one of our services to deploy to. And then she walks you through even inviting the bot to the Slack channel and interacting with it, so it’s a great read.
B: Yep, definitely. She doesn’t actually tell you though that some of the bots she wrote… [chuckle] I had to ask her to shut it down, I’m like, “Shut it down.” I’m like, “Your bot just keeps pinging me non-stop, all day.”
E: So, Cody Lindley wrote an article about Taming Your React Setup. Apparently, some developers think it’s difficult to get your React set up for an environment, to have your work flow, anyway. He outlined seven different configurations and he fully demos each way that you could set this up to use. I guess the modules that you prefer like React, with JSX or without, with or without Babel, and Webpack, and SystemJS, and all those things are detailed out in really step-by-step tutorial style so it’s easy to pick up and understand how to create those development environments that you wanna custom-tailor.
B: Yep. And I think the key here is that React is not prescriptive in your setup, because it’s only one small piece of a larger ecosystem, that it doesn’t prescribe necessarily all of the parts. And that’s kind of what he gets at in the beginning and that’s led people to believe that it’s React that makes it difficult, but, in a way, it’s almost like saying, “Well, a stick shift is more difficult to drive than an automatic,” and yeah it is, but it also gives you more flexibility, right? In a way.
B: Yep. But the command line is so awesome that the more hoops you jump through, it’s just more awesome, right?
E: The thing is I get in the mode where it’s like I’m losing the context of what the heck I’m actually doing with the command line. Like eventually it’s just me just furiously pasting other people’s command line scripts into the console and hitting “Enter” because it’s just too much to remember like what each one of these… I guess domain-specific language would be the proper term. You have each of these command line executables and then all of the options and parameters that go with each one of them, and they’re all written differently, and they all use their own kind of syntax, and it just gets to be a huge mental game.
B: It is a mess. And I would say sometimes it’s really important to figure out why it is you’re doing something, because you can get in this mode where you just do something because it’s what you’ve done. I always like to think of how behaviorists look at the way people will do things, and they could be doing it very inefficiently, but until it stops working for them, they actually will continue to do it inefficiently even when shown ways to do it more efficiently. I don’t know if that makes sense, right? Even in our jobs and as programmers, we can get into this mode where we’re actually using all this stuff just because we’ve always used all this stuff and, well, we have to install X and we have to install Y and you need to sometimes, I think, step back and look at, “Why am I using this? Is it actually benefiting me?” Because I think we’ve started layering on so many pieces that you get somewhat disassociated with each individual piece and why you’re using it.
E: At least in this case we have somebody like Cody to document this stuff for us and show us how to do it easier. Otherwise we’d just be beating our head against the wall.
B: No, we’re still beating our head against the wall, but that’s beside the point. [chuckle]
E: Next up, we’ve been doing a series on our Telerik Developer Experts. Do you wanna give folks an overview of what a Telerik Developer Expert is if they haven’t heard of one?
B: Sure. It’s just a program that we run for people who are very well versed in Telerik products and have been active within the community, and we like to offer like recognition for their efforts and the things that they do on behalf of our developer community. So we have this program that just gives them some of that recognition and helps enable them to contribute to other things that we’re doing and keep them up-to-date with all what’s going on in Telerik by Progress.
E: So these are folks who are writing articles for the blog and writing apps and blogging on their own blog on how they created an app using some of our tools and maybe speaking about our stuff at a meetup or conferences, and they’re consistently delivering material with our message and our products. And to show our appreciation, we have the program for them, and this week we covered Jim Holmes, and he’s one of our developer experts for Test Studio and he […] was our Test Studio Developer Advocate and he was also a Program Manager or Director of Engineering for Test Studio, that’s what it was. And Jen gave him a nice interview , and if you’d like to learn more about Mr Jim Holmes, go check that article out. Jim will actually be on the show in a couple of weeks here. He’s got some interesting agile workflow type of office politics point of view that he’d like to share and hopefully he does a better job of explaining it than I did. He has an interesting name for it so we’re gonna record a show on that and I think everybody will enjoy that.
B: Sounds interesting.
E: Yeah. So the next article up is actually one of my own. So, shameless plug… .NET Core went RC2 about two weeks ago, and there’s just tons and tons of changes. So we actually recorded an entire podcast on that with Jeffrey Fritz from Microsoft, and he gave us the insight into why some of those changes took place and what they are and what we should expect. So if you’ve been fortunate enough to not be keeping up with it, you’re probably better off than if you’ve been trying to keep up with it because just everything has been in flux. There’s a lotta changes to the command line interface. They’ve renamed the EXE there. So there’s no more DNX.EXE. It’s now .NET.EXE. That was one of the huge changes in the latest release. The project structures have changed, so you might need to go back and look at what File/New Project gives you in this version. And then of course, we released some of our tag helpers, and when I say we, Telerik by Progress products have released some support for ASP.NET Core tag helpers which is a new way of writing server-side HTML code, so that it’s got some nice features that make it more readable and easier for you to parse visually when you’re trying to create your server-side templates and stuff.
B: Well, and importantly .NET Core goes RC2 sounds, to me, it’s something like from Star Wars movie where somebody says, “Oh, my God, Luke, the .NET Core has gone RC2.”
E: So, up next, we have Ready-to-Use Grid UI for AngularJS Applications. So, if I’m not mistaken, this was one of our engineers that wrote this, right?
B: Yeah, it is. Konstantin Dikov.
E: So, we have a lot of UI controls and one of the biggest, most popular ones of those is the Grid, right?
E: So, we have Angular support for this Grid control, and this is for Angular 1, and we’ll have Angular 2 support soon, but there’s still a ton of people writing Angular 1 apps. I mean lots and lots of folks writing Angular 1 apps.
B: Yeah. And Angular 2 is still not complete, right?
E: Yeah. I think it’s a maybe release candidate.
B: Is beta or is it alpha?
E: Maybe beta. I think it’s still beta, close to release.
B: Yeah. So I mean even people starting new apps, a lot of them are still using Angular 1.
E: Yeah. It’s definitely not production ready, let’s just say that. So, what he did is write about some of the biggest frequently asked questions, and he answered the hows and whys about many things regarding how to get Angular and the Grid working together and how to do CRUD operations and everything that you’re gonna need to get some of the most difficult tasks done and relatively easy with the Grid control.
B: Yeah. It’s a really nice article.
E: And it kind of made me think back to the previous article with Jim Holmes, because in his interview he mentions that one of his jobs right now is to create unit tests for a custom Grid product that they wrote in-house, and he’s saying it’s extraordinarily difficult to get this thing tested and he wishes they would have just used a Kendo UI grid from day one and they wouldn’t have to worry about unit testing all of the problems that they’ve had, or all of the cases that they need to cover with this Grid, because we frankly do that all for you, you don’t have to worry about it.
B: Yeah. Even when I was a developer on a full-time basis obviously. I was all for… I don’t like having to reinvent the wheel. If somebody’s got a solution that’s out there, like this, especially for something as complicated as a grid. There’s no way that I wanna get into the grid-writing business.
E: This will probably come off as a sales pitch, but it’s not. If you just sit down for a second and think about how long or how many hours you’re gonna spend writing X feature for a grid and just look at how much you’re gonna spend on getting a good, solid grid with lots of features, sure, you can spit out a table element and fill that in, that’s not a problem, use Bootstrap to theme it. But as soon as you gotta filter that grid or sort columns in it or start doing some of that type of stuff, or doing CRUD within the grid and supporting accessibility and making sure its keyboard navigation works, that’s a rabbit hole you don’t wanna get down in.
B: Oh, yeah, absolutely. And when I look at the number of features in that grid, it’s like… You may not use them all, but even if you use some of them, you’re just not gonna wanna maintain that kind of thing all the time.
E: Yeah. I always had a subscription for Telerik before I even worked there, but the rule of thumb was, if it’s just data and I just wanna throw it out on the page, a table’s fine for that. We don’t need to take a dependency on a third-party library, but as soon as somebody’s like, “Can I sort this grid?” I was like, “Okay, time to get the Telerik libraries installed and take a dependency and call it a day.” And then it’s like flip a switch and they’ve got all the features they want added on. So, anyway, shameless plug number two of the day. So, back to the .NET world. We kind of featured an article in the newsletter about the changes that were being made to project.json . So, this is another .NET Core RC2 thing. And I think in the newsletter we actually got the wrong author. So, that was actually written by Scott Hunter from Microsoft and then posted by another person.
E: So, Scott Hunter wrote about some upcoming changes. So, actually in RC2, this did not change. What he’s writing about is what will happen in the betas that will take place after .NET Core 1.0 releases. So, for right now, RC2 will become 1.0, and project.json will not change whatsoever. But once the 1.0 comes out and they start working on the next milestone that will start changing project.json. And the reasoning behind this is, there’s actually a few things. So, one of them is, naturally with anything new, you’re gonna have legacy stuff that doesn’t work. And for Microsoft’s Win, […] they have people with legacy needs, applications that are of age. We’ll try to be politically correct with the terminology here. We have old applications that need to be supported, Microsoft has a lot of those. So, when they tried to change the project structure, naturally those people were kind of throwing up red flags everywhere, like, “Hey, help. We’re trying to create applications that can live 15, 20 years and this is breaking the stuff.”
B: And that was my understanding, that this was, in large part, due to feedback that they got.
E: Absolutely. So they listened to customers. Customers were saying, “We like MSBuild. We have it in lots of legacy applications that we’d like to move forward and not break completely and have to rewrite from the ground up,” and there’s a lot of things that they would have to recreate, tooling-wise, to support project.json the way it was going and it was gonna be a big, it was gonna create a big lag that they could just fix by going, “Okay, we’ll just use MSBuild moving forward.” So, what they’re gonna do is they’re gonna go back to the old project style, but keep many of the things that people liked about project.json. So we’re gonna have to put the best of both worlds when they’re done, which is nice.
E: Yeah, hopefully. [chuckle] I think they’re well intentioned and they’re gonna try to make this work the best they can. And them purchasing Xamarin was another thing that helped this move forward because Xamarin actually has a version of MSBuild that works on Mac and Linux. So they’re already halfway there with that purchase of Xamarin, so that’s gotten them a leg up on the situation so they decided, “Okay, we’re gonna go back to the old project style and use MSBuild if that’s what people wanna use,” and they’re gonna provide command line interface stuff for Mac and Linux to get MSBuild working on those systems. So, I hope that if you’re a .NЕТ dev, you caught something from that. If you’re not, you may have tuned out by now, but hopefully not. We’ve got some good stuff coming up. So, Nic Raboy is one of our TDEs, and he has pretty much been mentioned on every developer digest show so far because he’s always posting something about our tooling or some tutorial and…
B: For mostly NativeScript, but, yeah, he’s pretty prolific.
E: Yeah. He writes a lot. I wish I had the drive to write as much as he does. So we’re actually gonna have him on the show as well this month sometime. We’re gonna record that sometime next week and get it up on the podcast soon so everybody can hear what he’s doing and what kind of stuff he works on for Couchbase. But he wrote a tutorial on going from Ionic 2 to NativeScript.
B: Right. And then the big thing here is that Ionic 2 is also using Angular2 to NativeScript, which now has Angular 2 integration. So the idea being you’re not taking, say, an older Ionic application that was built on Angular 1 and trying to convert it. Anyway, his premise was that it really wouldn’t be that difficult given that they’re both running Angular 2.
E: Yeah. And one of the big things to take from this article is the fact that Ionic is using WebViewс to… It’s Angular and it’s using… It’s creating a mobile application but it’s using WebView to do that. And then NativeScript is actually using native APIs, and we’re talking directly to the hardware with NativeScript, so it’s a big difference there. So, if you could take your Ionic app and use pretty much the same framework to build it and use NativeScript instead of Ionic, then you can benefit from not having a WebView.
E: Yeah. One of the things about Angular 2, though, is it does allow this templating system to be changed from HTML to something else. So there’s probably some reuse there where you’re just changing out the template from an HTML to an XML template. So that’s really cool.
B: Right. Yeah. He said basically everything behind the UI specifically. It can stay very similar, but you have to take everything you did in HTML and just replace that template with an XML, with a NativeScript mark-up.
E: Nice, very nice. And that gives us a good entry to the next article up which is Covering Mobile Development Ecosystems by Mr. Brian Rinaldi.
In the end, I think it really boils down to what are the resources on my team? What are the skill sets on my team? If I choose to do one of these other options because we think that would be a better fit, do I actually have the ability to say hire or farm out or whatever to get that done? Because, in the end, we all talked about, say, like picking the best tool for the job, but in the end it really does boil down to people. And you’re not gonna go, “You know what? We’d rather do this in Xamarin, so we’re gonna go hire a bunch of C# guys and then start trying to build this from scratch with all new guys to join the company,” you know what I mean? You have to go, in large part, with what your team is capable of doing, unless you say you’re gonna just farm it out externally.
E: Yeah. And the stance that I always take on this too is: it’s not always a one or the other option. It’s not always should we have a mobile website or a native application. Sometimes it’s like, “Okay, we need an application that runs natively but we also need a website that can be viewed on a mobile device and both of those things need to be companions to one another and drive downloads to the them, to the application,” and stuff like that.
E: So, finally, we have one more NativeScript article. It is called NativeScript Android Application Package Size Revealed, and this is by Georgi Atanasov. He’s on the engineering team for NativeScript.
B: But, yeah so this article is really interesting because it delves into exactly what’s going into the package that we deploy for Android and why it’s significantly larger, say, than like you would get on iOS. And what’s causing that, what weighs around that if it becomes an issue for your application, and what we’re doing down the road to alleviate some of that weight. And the larger point here, I think, is one of the things I love about what we’re doing with NativeScript is we’re basically doing everything out in the open. We’re not just making it open source, we are being as open as we possibly can. In this case, admitting where we know there’s something we need to improve and being open about what the issues are and how we’re trying to improve it.
E: Yeah, transparency to the Nth degree here. And it’s really good stuff too, because it’s like the article we covered last episode where we’re diving down into this deep engineering decision-making process that we have, and if you’re not using NativeScript but you’re just geeking out on software engineering as a whole, this is still an excellent read for you.
B: Yep, I agree. I like the way he discusses it and kind of explains where these decisions were made.
E: And he does it in terms that people can understand if they’re not that tech savvy software engineer, but they’re interested in kind of some of the engineering that goes on in it, which is also nice.
B: Yep. Absolutely.
E: So if you wanna catch that article, make sure you stop by developer.telerik.com and click on the Telerik Developer Digest call to action on the right-hand side of the page. Make sure you sign up so you get those in your email and you don’t have to hunt them down twice a month when they come out. And then tune in to the podcast and listen to us share our opinions on what we read for those weeks.
B: Yep, that sounds good.
E: And, for the show, we have quite a few guests coming up. I know we kinda missed a show in the middle of last week.
B: Yeah, what’s the deal, man?
E: So there’s two Developer Digest shows back to back. We actually had kind of a difficult month scheduling folks. It’s busy for everybody, schools getting out and there’s a lot going on, people are traveling, conferences are spinning up and dying down again so we’ve got a big queue coming up with great people like Jared Farris and Julie Lerman and Jim Holmes and Nic Raboy will all be coming up on the show very shortly, so hopefully you guys subscribe on iTunes or SoundCloud. Make sure you guys leave us some feedback if you’d like. There’s feedback on the website or on SoundCloud and make sure you give us a like on iTunes, that helps us get more listeners and keep the show going.
B: Yep, good stuff.
E: Brian, thanks a lot for helping me out again buddy.
B: Yeah, no problem. This was fun as always.
E: And we’ll be back next week with Jared Farris on the Podcast. Thanks for listening. Bye-bye.