Java news - will Oracle sue us for using the Java name? Java 10 is live with a big new feature (local variable type inference) and JavaEE is now JakartaEE.
Plus some talk about upcoming courses - Kotlin Programming and Kubernetes.
Here's the link to the survey we discuss: The State of Java in 2018
Matt:Hello, and welcome to podcast number 13 in the All Things Java series. Some would say that's unlucky for some. Hopefully, not unlucky for us or our listeners.
Richard:It will be unlucky for me, I think.
Matt:I'm Matt Greencroft.
Matt:Good to see you, Richard, after I wouldn't let you out for the last podcast. You were busy away working on updating our courses, so we had a few complaints, I think, from our avid listeners that they missed your voice.
Richard:Yeah, really. Yeah.
Matt:They missed your rants.
Richard:I did have a few. I've neglected my blog, which is a terrible shame, and I don't know why. It just kind of fell by the wayside, really, and podcasting, I think, probably replaced the blog. I realised that's not really a good idea. I think blogs are still valuable. I know they're not fashionable now, but they're still valuable, so I put up a blog post saying, blah, blah, blah, the usual mea culpa, "Sorry for not updating the blog, da, da, da. I've been doing podcasts instead, but no one's listening to the podcast anyway, so it's time to start putting more effort into the blog."
And I was amazed. I didn't think anybody read the blog either. Then I had two comments, I think, pretty much straight away, saying, "I'm sorry to hear you're not doing the podcast anymore," so there's at least two listeners there. You're probably thinking I've probably planted those comments, but I think they are customers.
Matt:I'm going to go and look at your blog later and see if they're the same two listeners that I'm aware of or whether that means we've actually got four listeners. You never know.
Richard:It could be four. It could be four. So I did go back and edit the post because I realised it sounded like I was saying no more podcasts, which wasn't the case at all. But-
Matt:Excellent. Of course, you've also got a copy of your blog on the All Things Java site.
Matt:Which we haven't updated, so we've got two versions of both your blog and my blog out there at the moment and we need to have a think about that.
Richard:Let's just copy it across.
Matt:I can't remember what we did?
Richard:It seemed it was a ... Just link to them, that'd be much better.
Matt:Well, we'll have to have a look at that because at the moment it's copied across. So anyway ...
Richard:No, no, no.
Richard:Oh, yeah. I'm never not on the “HTML5 blah blah”.
Matt:Been a bit of news about that because, well, interesting that the article I was reading was saying that they think it might be something that was instigated by Oracle's lawyers, as a way of them demonstrating they are protecting Oracle's trademarks, rather than it being Oracle's desire necessarily.
Matt:But I was at a meet-up not so long ago where one of our two listeners that I'm aware of said, am I concerned about All Things Java? Are we using the word java?
Richard:Very interesting, yeah. Oh, great. Oh, that will be fantastic publicity.
Matt:Well, that's exactly what I thought.
Matt:I said to the guy, "Well, as we actually have customers who work for Oracle, so they would be telling one of their suppliers not to use one of their terms... It would be very interesting, but it would be great publicity." So if there's any of our Oracle customers out there who want to suggest it, I wouldn't mind.
Richard:Well, it would be ... If we did get a take down notice or whatever, it will probably a lot ... rather than renaming, it will probably be a lot quicker and easier to simply change the contents of the podcasts to everything about the beautiful island of Java and why you might want to spend your holidays there. And by the way, Java coffee is lovely as well. You could do that instead. Or Jakarta, if you ... Java in Jakarta.
Matt:Jakarta, absolutely. All things Jakarta.
Well, so watch this space. For now at least, we still think we're okay to use “All Things Java”.
Richard:Obviously, the big news is Java 10 coming out suddenly overnight, which I think must have taken everybody by surprise. I don't think anybody really believed that the six-month cycle was going to happen. I actually had another listener ... Hello, Mark. Mark's a great guy, a fantastic programmer, and he, just to demonstrate really how confusing this situation is, he sent me a message saying, "WTF, what's going on? I hear Java 9 has been abandoned and is discontinued and there's going to be no ... " Caused a real ripple. Twitter went bonkers the day Java 10 came out. I mean, people haven't even started using Java 9 yet, generally.
Matt:Right. But haven't Oracle announced ... Sorry, I shouldn't say Oracle. Haven't the committee announced that the next long-term support version of Java after 8 will be Java 11?
Richard:Yes, I think it's 11. Yes.
Matt:It is. So that's sending out the message, isn't it? That says, "Don't use Java 9 and Java 10. Wait for Java 11."
Richard:It depends, yeah, if you're wanting to be on the edge and all that, then ... This is a rare thing where I'm not going to be complaining about how boneheaded the whole thing is. It's kind of unusually kind of well done, as far as I can tell, but I just wish they'd not gone for full whole number increments. That is really confusing. This should be 9.1, 9.2, and then when we get to an LTS, the number should go up, probably. I mean, the pace of change now ... I think it's not ...
I mean, if you actually look at what's in Java 10, there's not much there barring one big headline thing that I'll talk about in a minute, but it's ... I think there is a big psychological thing behind the number going up. People tend to ... It kind of causes a cognitive load on people thinking that this is a big change. See, you can have people going on about, is it time to make the jump to Java 11 yet or should we be on ... That numbering is not quite right. But I will say, kudos for doing it.
Matt:Okay. Going into that numbering though, so most people believe, and I've got a website that'll back me up which we might mention in a minute or two anyway, are using Java 8 right now. There was a few people on Java 7, a few on Java 6, but most are on Java 8. So if you decide as a business, we're going to move to Java 11 because that's a version with long term support, you're probably not going to do it on day one. So you might be moving to a Java 11 when Java 13 is out, and there's going to be this constant, is everyone going to get used to being a bit behind? Which, again, is a slightly different mindset.
Richard:Very odd, yeah. Can't quite get my head around it. Really can't. So the big feature in 10, it's really taken me by surprise, this, is local variable type inference, which, it's not the right medium on a podcast to talk in detail about what it's about, but I've put in some code samples on my blog which, just, I mean, it's very simple. Basically, instead of saying, I'll go for the daftest, simplest example, instead of saying String string = new String(), you can now say var myVariableName = new String(). So the compiler will all just work out with the left hand side is probably going to need to match the right hand side.
Quite simple, but other languages do it perfectly well.
Matt:Yes, so var is a new keyword?
Richard:It is. They nearly went for let. That was a bullet dodged.
Richard:Let would've been fun.
Matt:Why would let have been fun?
Richard:Well, you know it's like basic innit, you know ...
Matt:Oh I see. Okay. I wasn't going to talk about this just yet, but I'm kind of going to be doing lots of stuff in Kotlin.
Richard:Oh, massive in Kotlin.
Matt:And of course, var means something in Kotlin, but let also means something in Kotlin. So had they chosen let, which var pretty much means the same thing, right? Mutable variable.
Richard:I assume it's mutable and immutable, is it?
Matt:No. Let is to do with running functions. Let's not get into that just today. I mean, its not part of this thing. But let has a meaning, right? So whereas var at least you sort of, you know it stands for variable. Its very clear and interestingly in Kotlin it means mutable variable as opposed to immutable-
Matt:So this is the same use of the term-
Richard:Yes. Now that was disappointing that there's no ... This has got nothing to do with mutability sadly. I did read the spec and it does talk about this and they argue that that concern is orthogonal, as they say, to the concept of type inference and they decided just to keep that out. It would have been confusing. It would have been difficult, it would have been a big change in fact.
Richard:So I hope that's going to come to Java at some point in the future, or move to Kotlin of course. So yeah, that was a headline feature anyway. There were about 9 or 10 other, which is the usual sort of garbage collection improvements, a bit of tidying up, a very minor change. But that will be, so I use an example from the Spark course that we recently released, which I think Spark in Java, that was the revelation from doing that course, really. Spark in Java is almost as clean and simple as doing it in Scala. Its not far off. I've seen a lot of presentations where people laugh at Java's verbosity, but they're using Java 7. Once you're using lambdas, it's all quite nice. Apart from tuples. Tuples are horrible. But if you want to see that buy our course and you'll find out, apart from the tuples.
But when you bring vars into the equation its even nicer because you're not constantly replicating data types on both sides of an assignment.
Richard:So its all good.
Matt:Okay, well that will be interesting. And I guess in practical terms, though, all that really means, by having var as a keyword is its slightly less typing – is it any more than that?
Richard:Oh yeah. It's syntactic sugar, really.
Richard:I think that's what I argue on the blog. Given that what a lot of programmers will do, I certainly do this myself, is when things get complicated on the right hand side of an assignment, you sometimes lose track. Is this a, right this is a new JavaRDD, this is a JavaPairRDD with angle brackets, a tuple of a string and an integer. Have I got that right? And you use the quick fix to work out what the left hand side should be and that kind of thing. So the compilers been doing that, not the compiler actually. Would that be the compiler? I'm not sure. Anyway the IDE's have been doing that for a long time anyway.
Richard:Its just baked into the language, so yeah, less typing. That's all. But that's a good thing. And the other news ... I don't know when this happened because it’s not that interesting to me, possibly. Not interesting to us, necessarily. There is something that's happened since the last podcast I was on, is that Java EE has now been renamed, a rebranding exercise e-
Richard:Oh yes and this is a nice idea. So its now Jakarta EE.
Richard:Instead of Java EE and there's a ... I have to admit I've not bothered doing any research into this whatsoever. That's all I know.
Matt:Do you know that's probably it, actually, because I'm exactly the same there. And I think I might have mentioned this on the last podcast, the one that you weren’t there
Matt:But literally just in passing, “or should I say Jakarta”? It was that kind of thing.
Richard:Yes. Yeah, I vaguely remember that.
Matt:Yeah. But actually it is just a brand and there's no other-
Richard:Well, the important thing behind it is that it is now being governed by the Eclipse Foundation-
Richard:So this suggests and certainly the rhetoric suggests that it's going to be more agile, it's going to be more releases, so similar to Java and there's a lot of talk about it becoming more cloudified. So I mean, that's what they've got to do. They've got to move into the kind of area that Spring have moved into if it's going to continue to be relevant.
Richard:So it's a funny thing, this. I mean we know ... You've been wanting to give a link to a web page which has a survey on it, of who is using what at the minute.
Matt:Yes, so we are going to put a link to this in the show notes and it's a survey of around about 5,000 developers and they're looking at, well they call it “The State of Java” Survey, and I confess I haven't spent time looking at who's actually behind this, what their agenda is and so on, but it seems to be an annual thing that they do. And certainly in that, I mean the highlights, they're saying, is we've already mentioned that the vast majority of people are on Java 8. They're showing it as a pie chart without numbers on, but I would estimate that that's around about 85%, in terms of Java versions.
They talk about Spring versus JavaEE and I would estimate again, looking at the pie chart, its something like 75% of people are using Spring. About 10-12% are using JavaEE and then there's others in there-
Matt:That sort of make up the gap. So Spring is very much clearly what they’re more widely using and-
Richard:That must be quite a change since ... So back in 2011 we released a JavaEE course. Frankly not because we were excited about it, but because the market required it.
Richard:And it was quite a good course. It was our second best selling course, I think. It did very, very well for us. So you would have said around that time, 2011, I don't think it was quite 50/50 but the balance was a lot, you know, a lot of our customers were saying we don't use Spring. We have to use Java EE, so give us a Java EE course. That wouldn't happen now. And that kind of bears that out.
Matt:Yes. I guess it's the larger companies with legacy systems running in Java EE that are recruiting new Java EE developers, but as you said, the cloud or the current ... Yeah, I can't remember what the word is now, trend, you know to build microservices, smaller things that you're deploying in scalable infrastructure in the cloud, that's not JavaEE. That's not where it is, is it, really?
Richard:Well I suppose ... I mean you demonstrate on the Wildfly courses that we've replaced the JavaEE courses with that you can be quite agile with traditional JavaEE. Its not ... But that's clearly the challenge they've got to address.
Richard:They've got to move in that area and they've got ... I mean 10% and it's a declining 10% is the important thing.
Richard:They've got to get that back up to the 40's and 50's if they want to stay relevant. So I kind of ... I don't know what, I don't know how I feel about this. Something inside me just says I hope they do. I hope they do sort of get a bit of a revival there, but I can't justify that feeling.
Matt:Yes. I really ... It's interesting how well Spring is doing, really.
Richard:I'm amazed at that. I'm amazed the others, and you'd think there'd be plenty of shops who are using, I don't know, some kind of combination of Apache libraries or ... I'm suspicious, I have to say, at those figures.
Matt:Well this is 5,000 developers, right?
Richard:5,000 developers of what? Who are they asking? I'm not clear.
Matt:Yeah, I don't know that. I apologise. I haven't done the research into the credibility of the site.
Richard:It may be 5,000 developers who identify as enterprise Java developers, possibly. Because you would think, if you throw a brick and you know, find a random Java project, the kinds of projects we're hearing about are using Kafka and Spark and all this massive soup of-
Matt:Well there's no, I don't think, any mention of Android on here, right? Now clearly there is a, you know, a number of Android developers who are using Java, so they're not our target market so we don't really talk to them but they must be a part of this
Richard:You’re right it must be a focused survey, that. But certainly Spring is huge right now and I think one of the figures on there is that of those using Spring, almost all of them are using Spring Boot. It doesn't mean that they're not using traditional Spring as well, but-
Richard:Very few are, "No, we're just using Spring and we're not using Boot."
Matt:That's correct and I don't think it gives you a figure there, but it's almost exactly and exact quote you've just said here. Almost all of them are using Spring Boot for production. So yeah, the other thing that I thought was interesting was use of different IDE's-
Matt:So just over half on Intellij and just under a half I'd say on Eclipse, there's a few others in there-
Richard:Yeah it's quite less than a half, I seem to remember on Eclipse. It's a chunk below a half.
Richard:Well its 30, probably 35%
Matt:35%, something like that.
Richard:Which is, yeah, it's a wake up call. I mean it is no secret that Matthew now is just a total Kotlin. All he talks about is Kotlin. It's Kotlin this, Kotlin that and he's a total Intellij fan boy now.
Matt:Can I just say this makes a refreshing change from you wittering on about how I'm meant to be the clojure expert. Thank you for that.
Richard:Yeah, I mean clearly you are going to go and start using Intellij now.
Matt:It’s funny that, because obviously ... For 90% of what you do, which IDE do you use? You don't even notice that you're using something different and I've started playing with Kotlin, which means I'm using Intellij. Although you can do it in Eclipse, it's clearly better in Intellij and it's little things like the fact that you can't save a file because it does it automatically for you. It's all those irrelevant things that are happening behind the scenes. Actually 99% of the time I forget which I'm using. So okay, some of the key presses might be different for some of the functions, but-
Richard:Our friends at Jetbrains will not like you for saying that.
Matt:No, well I’m obviously not using all the advanced features of their idea.
Richard:We should fill in and ... I know we've done a separate podcast on Kotlin but just in case people are not picking up on this banter, Kotlin of course, is guided, governed by Jetbrains who make Intellij ... I'm not sure-
Matt:They invented the language, so yeah, I'm not sure of the relationship there and although we talked about it before, I've only really in the last month, got to grips with the fact that it genuinely could be the JVM language other than Java that's going to have longevity and wide adoption.
Matt:And there's a number of things pointing to that. I mean, we probably mentioned the last time that it's a first class language now for Android. So Google are saying if you're building an Android, you can build in Kotlin. We fully support it, so ... Which obviously is a big push but interestingly on that same website, and they look at JVM languages you might be using other than Java and the size of them, and what's really interesting there is that the most widely used of all the people they interviewed, was Groovy.
Richard:Yeah, I was shocked at that one. I wonder if people are saying Groovy because they maybe use Gradle and that's it. They don't do anything else with Groovy?
Matt:Well, except that when you look at the build tools, Gradle is okay, yes to be fair it's just under a quarter that use Gradle-
Richard:So that quarter are going to be saying we use Groovy, maybe. I don't know. I can't believe there are that many developers… Groovy's great now. I don't have a problem with that.
Matt:Well we associate or I associate Groovy very much in with Grails. And actually, I mean I know of a business locally that does use Groovy. They use it as a prototyping language. So they don't run their production systems in it, but it's certainly a starting point. But looking at their list then, they're saying Groovy's number one, Scala's number three in terms of adoption and Kotlin is the number two now.
Matt:And I think not only is it the Android side but of course you can build Spring Boot applications in Kotlin, and that's what I've been playing with.
Richard:If only there was a training course available from somewhere that showed you how to build Spring Boot applications using Kotlin. Well it would be great, wouldn't it?
Matt:You might be letting the cat out of the bag, but that will be the next thing I'm working on.
Matt:And you know, we won't whittle on here about the advantages of Kotlin over Java, but actually what I'm doing is a way of learning Kotlin as I'm taking an existing Spring Boot application that we've got and I am, I'm not going to say converting it to Kotlin. I'm rebuilding it in Kotlin, because I think if you do a conversion you lose some of the intricacies of how you might be able to do things a bit differently and a bit more Kotliny, if that's a word. So I'm currently going through that process and it’s interesting. There's a lot of very nice features that I think will give you more reliable software going forward. I'm getting quite excited about it and the word on the street, if you like, and I actually met ...
When we did our first talk on this podcast about Kotlin it was because we'd been a to Meetup and we name checked the guy who spoke at that Meetup was called Andy Bowes if you recall. And I met Andy Bowes recently and he gave us, so name check back to you Andy. Thank you for listening to the podcast. He's one of our two listeners that I'm aware of. But he was saying to me that we really should get into Kotlin more and I think I'm getting persuaded.
So yeah. Interesting that that, you know, if you want to be doing other JVM languages, it seems now Kotlin, given the current uptake and its already overtaken Scala, I think it's a shorter learning curve for Java developers to move onto Kotlin and some of the really nice features from Groovy are in there as well. So I'm voting for it. That'll be my next course, definitely. There you are. You've heard it here.
Richard:Right. Can't wait. I shall buy it. Definitely. I'm not working on anything.
Matt:Are you not?
Richard:Well I have announced a course, so that is listed on the Virtual Pair Programmers’ catalogue now.
Matt:And what course is that, that you've announced, Richard?
Richard:That is Kubernetes but I'm not kind of jumping up and down excited about it because that is the natural evolution from our Docker series, so it’s the next obvious step in our Dev Ops line.
Matt:Can you give us the one line on what Kubernetes is?
Richard:I can't do one line on anything. I can give a short lecture, of course. Probably with a rant in the middle.
Matt:Oh let’s have a rant. It must be time for that.
Richard:No, I've nothing rant worthy in there, really. But I am a little bit ... So with my course productions at the minute, I'm starting to do things that are ... I think ... Sorry, I'll back up. It's fair to say that perhaps traditionally our courses have been established technologies. Things that are well used, well understood and that gives us a certain ... You know, we weren't cutting edge necessarily in what we did and that's a good and a bad thing. But you know, we were solid.
And now with the Dev Ops line, I've been very much working in areas that are changing fast and the Docker course, it's a year old, will be a very old Docker course and so I am starting to include things in courses where I'm not sure if this is going to be a success in the industry because its relatively new. And a good example is with the Docker, I think our two Docker courses are really good but the second Docker courses focuses on Docker Swarm, which is how you ...
And Docker's very nice in that you build containers, you build container images, it allows you to partition your applications, ya, ya, ya, ya, ya. But how do you manage them in production? How do you capture that this application needs these 57 containers and they need to be configured in this particular way? And I took a decision and Kubernetes can do that by the way, and Kubernetes has become, over time, I think kind of at the minute the industry standard. It's the default option for doing that.
Matt:And is that what is meant by orchestration?
Richard:So its an orchestration tool. But for whatever reason, when I was working on the Docker courses, I was aware that Docker Swarm existed which does the same thing. And we hadn't used Docker Swarm, but I felt, and it's a decision that I think I regret now. I felt that if I'm doing Docker courses, it should be a complete Docker course and we should include Docker Swarm.
Richard:So I spent a long time building the Docker Swarm part of that course, all the time thinking why would I use Docker Swarm over Kubernetes? What am I losing one over the other and I realise now that I've got a finger in the air. I mean, I don't follow this every single day but it seems that the industry have kind of agreed that Docker Swarm is not the way to go. Kubernetes is where the, you know, the cutting edge development's going in. So we're kind of ending up now with these courses that have got topics on them that I'd rather weren't there, necessarily.
Richard:It's a bit awkward, that. And so I'm rambling, really. I ramble rather than rant, I think. I'm rambling really because my thoughts are a bit unclear on this. I wish I'd done Kubernetes a lot earlier. I wish I'd done it six months, a year ago. It is late, apologies for that to everyone who's listening. Because I allowed myself to digress into what I thought might be, you know, hang on if Docker has kind of got this stuff built in, maybe that's going to become the standard and I love Docker Swarm. It was fun to work with, but Kubernetes is definitely where it's at.
So Kubernetes is quite easy. My slight concern is, as you know Matt, writing a course is a nightmare. It’s horrible and it should be, because what's the point of having a course if you're not going through some pain, that you're fixing that pain for the listener?
Richard:There's no point doing a course if it’s all, oh this is dead easy. Start there and you know.
Richard:And almost Kubernetes, once you're up and running, it is very straight forward. As long as you already know Docker because it orchestrates Docker containers. If you know that, I don't think there's an awful lot, really there. Except for installing the thing. What a nightmare installing is. So I've got a Mac rig, a Linux rig, a Windows rig and the Windows is very different, depending on whether you're on Windows 10 Pro or Windows 10 Home and then it’s different again on Windows 8 and before. So all these combinations.
Well I was not able to successfully install Kubernetes on any of those machines, all for different reasons.
Richard:So I've been untangling that for weeks now. Now anybody would be able to sit down at their particular rig and get it installed, maybe with two days of pain.
Richard:So you know, these are not unsolvable problems, but no, for a course we can't say in Chapter One, "Installing it's really odd. Go off and do that, come back to the next video when you've done it." We've got to take them through it. I mean, it's the most tedious recording you can imagine. Most people won't watch it anyway because they'll go off and install it themselves, but you've got to do it. And so I'm not enjoying that right now.
Matt:Okay but once that's done, it's going to be a very short then, is it? If its very straight forward, or is it-
Richard:I'm hoping it won't be short because we're going to do the usual thing with the Virtual Pair Programmers Courses and it's going to be, we're going to take a production ... Obviously heavily cut down – I’m dusting off the ancient old Fleetman application again, which we did on Docker Swarm, so it'll be a good way of comparing the two, I guess. And yeah, we'll be taking it through to be playing with some real hardware.
I'm kind of thinking now that we've been very locked in to AWS and that's, you know, I mean it's the leader but it would be good to show it on Azure as well and the others. Google App Engine, IBM's got one now-
Richard:We probably can't do all of those but it would be good to, maybe. I don't know. So-
Matt:We'll have to think about that-
Richard:So Kubernetes will be in May, so we're on the first of May now, so it's going to be one day in May. I don't know when. Usually my track record, its generally on, like May 31st at 11:59PM UK time.
Richard:One second off midnight but I don't think that's going to happen this time.
Matt:Okay. Well I'm not giving a date yet for Kotlin because I've got a lot of work to do on that one first. Really just getting ... Learning it myself sufficiently that I know I can actually produce software that would be production standard and this is ... And dealing with the issues and particularly around Spring there are some choices you need to make around how you work with hibernate, posting data back from a web form to the server. That requires you to build classes in a certain way if you're using Kotlin. It's not a big issue but there's just some design choices to make, so we need to ... I need to make sure that I'm going to say the right things in terms of what is the production standard and actually when you have got a choice, what you should be considering. So I'm working on that still, so I'm not going to give a date for Kotlin. But it is going to be definitely my next one.
Richard:All right. I suppose we'll get off then and get back to work instead of waffling on about it.
Matt:Ah, okay. Yes.
Richard:Maybe. So I will just say that, you know, as part of recording the Kubernetes course ... So yeah, another thing is we've got this long series of courses on Microservices at Virtual Pair Programmers and that is very much a fast moving area. So we've got a massive pair of courses, in fact, that use the Netflix stack for microservices. And I think that's really valuable. I'm sure a lot of people are very interested to see what Netflix are using, etc., etc.
But I've come to the conclusion that, you know, some projects probably rely on that stack but it’s certainly not necessary to build a microservice architecture. And there are a lot of other ways of doing it. So I think I've realised for the Fleetman reference application for this course, I'm simplifying it down and taking out any architecture that's not absolutely necessary.
Richard:But also I'm trying to make it so that it is built to more modern production standards and there is a link to my GitHub repository on the Virtual Pair Programmers website. So if you go to the Kubernetes page it says you can follow my progress on building the code and you can follow my commits. I'm not actually pushing that regularly but when I do a push, you know, the repository will move on a lot. And I decided that there's a front end built in Spring MVC. Its actually on Spring Boot but Spring MVC.
Richard:Which is quite a ... Yeah, and I've found I'm still not, every time I'm working round I'm thinking am I just wasting time here, polishing something that isn't ... I mean it's of no relevance to Kubernetes at all. It’s just going to become a container, you won’t even have to look at the code, but I'm doing it anyway.
Matt:But we do get customers asking us from time to time are we planning a course on, and its often Angular, Node JS is the other one we've been asked for.
Richard:Yeah, we need it.
Richard:There's no relation at all.
Richard:Well I'd say it's a terrible starting point to be honest…
Richard:Well the only disagreement that we've had on this podcast-
Richard:That it's a terrible, terrible starting point.
Matt:So you know, what would make us as a company want to teach Angular as opposed to C#?
Richard:Well simply because it fits in with the architectures that modern projects are building.
Richard:You build your middle tier with REST. It doesn't have to be REST but it could be exposed as REST services
Richard:It's a sweet combination, a lot of projects do it. Whereas your argument about looking at C#, well yes, C# is great but you're just swapping out the Java for C#, and there are better people who teach C# way better than we'll ever do, because they've got 20 years experience of it.
Matt:So you could see we might end up one day with an Angular course, but its very much the Angular just enough to be building simple front ends to hook into-
Richard:Which is how Angular's used. Yeah. That wouldn't be a simplification and you say one day, I mean, I'm talking about this is June. I think we need to address this fast.
Richard:We're looking very, very dated and it was actually Jon Humble, who I assume is listening to this podcast. You know, he answered a question, a recent ... The Scala versus Java thing. I think the question was and Jon can correct us if I'm wrong on this, but I think the question was how would I build a web app in Scala? I don't ... You know, this play framework isn't it?
Richard:So that is the way, and I'm always very slow at picking up on these things and I've been too slow getting into that, so time to address it, I reckon.
Richard:So I've burnt up some material there unfortunately. So maybe the next podcast won't be about Angular, but certainly we'll be releasing a course on Angular. We're not going to be Angular experts, we're not going to pretend to be Angular experts. So you're right there about what you were saying, the angle we take has got to be right. We're not saying this is the definitive Angular course that you need. You probably want to get somebody else's Angular course after doing ours, maybe. But we'll be showing you how it slots into the architecture and fits into Java build tools and all those kinds of things.
Matt:Yes and actually, I guess, a lot of our front end stuff, you know, the courses we've got on Android. We are not putting ourselves as being Android experts, but it's enough to get you started and enough to give you an overview as a primarily back end developer, you know, to get a bit of a flavour. So if we're taking that attitude that sounds good to me.
Richard:Yeah, I think so. The dangerous thing that we must always avoid this, becoming evangelists. So I'm being a bit pithy there about you and your Kotlin. Kotlin this, Kotlin that, Kotlin the other. We've got to avoid being evangelists because I mean, I think Angular is beautiful.
Richard:And it just absolutely blows me away how fantastic it is.
Richard:The model is beautiful and I think that's really dangerous. If I do a course now on it, I'm going to be saying, "Oh this is fantastic." That's not what we're about. We're about saying, "Oh this is a nightmare to work with. These are the problems." And that's what comes from, that's where expertise comes from. You've got to get past that fan boy stage and you move into a more experienced, rounded knowledge.
Richard:And getting there is, it's hard work but-
Matt:But I think it’s, when you're enthusiastic about the thing that you are working on, it's a lot easier than when you think we need to do a course on X because we've promised it-
Matt:And actually, it really isn't pleasant and we're really getting stuck with it-
Matt:You know, so at least it should be a more enjoyable experience-
Richard:I guess, but I am mindful of ... I just think back to we nearly did a Grails course- Grails gets a mention on every single podcast we do. And we so nearly did a course of Grails many years back and we just missed out every ... What was it scheduling problems or something? I don't know. We just never quite got round to doing it and my goodness me, do I look back at think bullet dodged. We don't want to ... And we would have been like, "Grails is great!" Because we'd had all this success with it and we didn't know that all the pain and nastiness that we had with Grails was just around the corner- And we'd have led loads of people over that cliff and we have got the blame.
Matt:Okay. But the last course I was really enthusiastic about was Thymeleaf, right?
Matt:And I still really like Thymeleaf.
Richard:Yeah, but you're using your experience there, right? You know HTML well, you know XML well and you've worked for years in situations where you've had to pass work off to web designers-
Richard:And you've had to round trip with them. You've got the war stories there. You've done it. You were enthusiastic about Thymeleaf not because it was a new shiny thing that, you know, you just discovered and were shouting about, it's because you knew it was going to solve your pain.
Richard:And it does, so no problem.
Matt:And it's a more pleasurable experience than JSP-
Richard:Well, yeah. Banging your head with a brick for 10 hours is more pleasurable than working in JSP. Of course it is, so you were using your experience there. Whereas when you start on something like Angular-
Matt:Yes and I guess that's always one of our challenges, is identifying what is it that people are really needing? And you know, we get that really by talking to customers, talking to people at Meetups, seeing who's out there and what they're doing and I'm definitely ... That's why I'm getting the sense that Kotlin is where-
Matt:Is on the ascendant. You're-
Matt:You're now talking about nothing but Angular… I think we're both getting over tired, aren't we? So maybe we should call it a day on this podcast.
Richard:You have your laptop in front of you and you're programming Kotlin while we've been talking. We can't get a word of sense out of you. So I don't know what the next subject will be, and the next podcast, we'll keep them regular. I find if I'm still welcome as a guest on the podcast I will happily come and talk about what's happening, but a few weeks, I think.
Matt:Yes. Well we've both got plenty of work to do to keep us busy for the next couple of weeks, so yes, expect one hopefully before the end of the month but we'll see how we get on.
Matt:Lovely to speak to you again, Richard.
Richard:Good, good, good.
Matt:Thank you for listening out there if anyone is, other than the two / four that we know about.
Richard:See you on the next podcast.