Lightbend Podcast: Goodbye Activator, Hello Tech Hub, and Meet Lightbend's New Tooling Team
In this podcast, we sit down with the team lead for Lightbend’s Tooling Team to discuss the new Tech Hub, the decision to say goodbye to Activator, and the new roadmap for the long-awaited sbt 1.0.
Join the DZone community and get the full member experience.Join For Free
in a recent blog post , we announced the eol for activator and described a new direction for getting started with lightbend tech hub. including a rapid project starter and a growing list of technical guides, this new, online experience makes it simpler for developers to understand what is possible with our reactive platform technologies akka, lagom, play, scala and lightbend enterprise suite.
in this podcast, we sit down with eugene yokota , team lead for lightbend’s tooling team, to discuss the new tech hub, the decision to say goodbye to activator, and the new roadmap for the long-awaited sbt 1.0.
ow : good day, all. this is oliver white, chief podcaster at lightbend, welcoming you to today's show. i'm with eugene yokota, team lead for lightbend's new tooling team, and the guy who's been doing most of the heavy lifting with sbt for several years now. today's podcast discusses a few topics. namely, our new lightbend tech hub that features a growing set of guides, as well as our fresh getting started experience, which we recently unveiled as the replacement for lightbend activator scheduled to be eol-ed on may 24, 2017.
eugene will also tell us what he and his tooling team are focused on and what to expect in the coming months. so eugene, i'm so happy to welcome you to our podcast program. how are things going with you these days?
ey : thanks for the introduction, oliver. i'm doing fine, i guess. working hard towards the sbt 1.0's next beta , actually.
ow : wow. that's excellent. now, sbt 1.0 has been a long time coming i understand.
ey : it has been a pretty long time coming. yeah.
ow : well, we'll get into that in a minute. so first, i think the question that's on a lot of people’s minds is what happened to activator? it was very popular. it got quite big. would you say that activator was possibly a victim of its own success in a way?
ey : to some degree. i think the activator was sort of our main way of getting started with reactive technology. and if you kind of scroll back over time to 2012/2013 when activator came out, i think it was our way of trying to improve the ecosystem by having a tool that you can just download on your machine and get started with running play or something like that out of the box. and at the time, i think doing so using just open source tools was kind of tricky because you had to write your own script to install your sbt and things like that.
so i think that was one of the key motivators behind the creation of the activator. but at the same time, i think there were a lot of complications. because it was a download tool, it needs to work on a lot of different machines and different network environments. so i think its heart was at the right place, but the implementation became too complicated for the goal it was trying to solve. gradually, i think people started just using the open source tools.
sbt — in the same years — became more and more friendly in terms of the dsls and the install experience that we have been trying to improve.
ow : so what did you and your team do to make the new getting started experience different and, hopefully, better?
ey : i think the spirit of the getting started is still the same. we want to make it so that even if you haven't really been following up on all our build tools and things like that, get to sort of like a “hello world” state pretty quickly. so one of the lessons we learned is instead of doing a download tool, we tried to keep everything in the browser as long as we can. so things like tutorials: tutorials were a cool part of activator, right? there's template system in tutorial.
and you can get to learn about what play is and akka actors and all these different things. so we're now moving these tutorials to a website. but these websites are also github repositories that are managed by different teams. so when you send a pull request, it gets automatically reflected into a tutorial that also has the accompanying code examples that you can download and follow along. similar to the activator experience, i think.
ow : so it's a lot more integrated and not living in the activator silo.
ey : right. exactly. and it would actually use the real build tools like sbt or maven. so you start off with the tools that everyone else is also using.
ow : i believe the name for it right now is rapid project starter that you're referring to. (editor's note: see image below)
ey : yeah. i don't think there's a real name for it. it's been called a project starter and kickstarter and different names. but essentially, it's the tech hub, which is a new portal that we're building for developers. and one of the main features is to have this ui that you can quickly start new projects. and with that, there's also the guide pages. so the idea is sort of start with a problem statement. like you want to build a restful api. how would you solve that using the lightbend way?
and these guide documents would go through your problem, and kind of walk you through it implementing using play or something like that.
ow : that sounds great. i notice that giter8 is one of the main features that we're kind of working with on the project starter. how does that work?
ey : yeah. that's kind of interesting. as we're eol-ing activator , which like i said had a lot of really interesting ideas that actually worked well, i'm essentially breaking it down and reverse porting it back into sbt. and “activator new” is a way of starting a project if you're already familiar with the command line tools. so if you just type that, it will let you pick different templates.
so giter8 is actually an open source tool that's existed for quite a long time. it was originally started by nathan hamblin. so instead of central repository like activator, it just uses the github repository to post different templates. so if you have a github account, anyone can create a template. and sbt is integrated with the giter8, so if you type "sbt new" and your repository name, then it will start a project quickly like that. so from the command line, you can also start a project.
so the tech hub also integrates with the giter8. so if you make a giter8 template and you want to start with a lightbend technology, you can go to tech hub. but if you are already familiar with sbt, you can start with using “sbt new,” basically.
ow : that's good to know. so what would you tell people that are currently using activator? what should they do to prepare for the end of life and to try out our new getting started experience?
ey : yes. so if you're already using it — first of all, i think the command line experience of activator was essentially a wrapper around sbt. so a lot of that will basically be exactly the same. you can just switch over to using sbt's command line. if you're using the template of the activator, you want to make sure that those templates are moved over to giter8.
there's a blog post that i wrote showing how to migrate your templates from activator to giter8. it's mostly changing repository names and putting it into either your company's git or your public github repository. so that's mostly it.
ow : and what about for those of our fans out there who have actually built their own activator templates and have shared those with the community?
ey : yeah. i recommend them migrating to the giter8 templates, basically.
ow : all right. and all of that can be done on developer.lightbend.com , which is where you find our tech hub. that's correct?
ey : yes.
ow : excellent. so i'm noticing that sbt is really taking a front and center role with a lot of the stuff that we're doing with lightbend tech hub and elsewhere. and i guess it's a good time to talk about our new team that you're the tech lead of. and congratulations. we're calling it the tooling team. so what is the tooling team and what do you guys do?
ey : so i think there's been a history of tooling team like things at lightbend / typesafe. i joined under josh suereth. it was originally called q branch. and then it became reactive platform team. and then now, essentially, we're sort of going back to its roots of being the tooling team. there is dale, who is the sbt committer and he's super active in the community talking about sbt. and there is antonio (tony), he works with dbuild and other tools.
so essentially, like three of us, we are the — we make tools in the open source as well as some of the tools that are used internally within the company. a good example of that could be paradox, which is a markdown engine that's used by tech hub, was originally created by peter vlugter [of lightbend]. but we kind of took it and packaged it up so that the other teams can also use these things. so that's basically the tooling team.
ow : right. so earlier, when we first started talking, you told me that sbt 1.0 is on the horizon.
ey : yep.
ow : for people that aren't aware of sbt, can you just give us a really quick rundown of what sbt is? when it kind of started and where we're going with it?
ey : so sbt is the build tool that is used by many scala projects, basically. and one of the key features of it is that it has the incremental compiler. and also, it has sort of like a terminal interactive shell that you type in "test" and that runs test inside. if you typed "compile", it runs compile inside. so it almost acts as a lightweight ide kind of experience. you basically have editor and sbt and you can do a lot of things in there.
and people also have written a lot of plugins to do a whole bunch of different things. i've written sbt assembly to make a fat jar for deploying and stuff like that.
ow : is sbt what enables play framework and also lagom to do instant code refresh without having to wait at for compile, and restart, and so on?
ey : yeah, that's correct. yeah. so sbt is essentially like a platform on which play is written on. so using the plugin, they almost made a whole different thing in there. because you don't have to do anything once you start on play. you just have to hit refresh and it'll automatically compile. but yeah, it is written on top of sbt. yeah.
ow : so sbt 1.0, what's the story behind that? sbt's been around for quite a while. and we're seeing a 1.0 on the horizon. what's a little bit of the history there? and what are we looking forward to with 1.0?
ey : we kind of talked about sbt 1.0 for almost as long as i've been with lightbend.
i think 2014? and sort of a back history is that we didn't want to make a big jump to the sbt 1.0 because it's just a dilemma. right? you want to be able — it's almost like a 2.0 syndrome. you want to add a bunch of stuff. but if you add a bunch of stuff, it's going to break it. right? so we decided essentially to start adding a bunch of new features into sbt 0.13. and that's basically what's been happening in the last three years.
so now that scala 2.12 is out , i think we're kind of ready to say, "okay. let's just ship this with whatever we have and stabilize this and call it sbt 1.0." so that's sort of a quick story on sbt 1.0. but one of the major things that's happening is that we broke the code apart into a bunch of small pieces. and we created a repository. so i think in the beginning, i said, "one of the key features of sbt is its scala incremental compiler that mark [harrah] implemented."
it's been improved over the course of different years by others as well. you know, gigahorse has implemented name hashing and things like that. but it's sort of like almost a crown jewel of sbt that it's this difficult core feature. but i thought it should be kind of given up to other build tools as well. because i think different build tools also need an incremental compiler. so we split it up into calling it zinc on its own.
so now scala center , and twitter, and other companies can basically come in and give us ideas and improve the incremental compiler as a community. so i'm basically maintaining it more as a lightbend person would maintain instead of just purely for the sake of sbt, essentially. and i think zinc is too important to be just kept for one build tool. so that's what's kind of happening. and we're going to see really interesting improvements for zinc 1.0 that will be shipped with the sbt 1. so that's one of the main features.
ow : wow. that's really fascinating. yeah. without you, i have a feeling that we wouldn't be where we are today even in the slightest. you mentioned a couple other tools that your team works on. dbuild is one of them. can you tell us about that quickly?
ey : sure. dbuild started with josh and tony. and most famously, it's used for this thing called a community build. where the scala team uses it to check if the new version of the scala would work against existing open source tools. so it has basically dozens of projects in there. and it's able to rewire the dependencies and then build a different project from the source. so that's one of the tools that we maintain.
ow : and you also mentioned, i believe, some kind of enterprise features that are part of lightbend reactive platform that your team works on. can you tell us about those?
ey : sure. yeah. so the other big responsibility within the tooling team is that we maintain infrastructure to run a lot of things. the enterprise suite is lightbend's commercial platform. so because we used to be the reactive platform team, one of the things we do is we run the authentication service that integrates with the commercial bintray repository. and then we'll authenticate you. we'll issue some token and make sure it all works and stuff like that.
another project that we're currently looking into is integrating with white source to do license checking and things like that. so these are things that happen alongside with our sbt stuff.
ow : and i guess my final question for you is when is sbt 1.0 aiming to be available? the dreaded question. i know. it's a terrible thing to ask.
ey : we now have a roadmap. so i would say go to tech hub and check out our roadmap. so the first beta actually shipped a month ago. and the idea is that we're going to do a couple betas and then release candidate. and then we're going to ship. so these are all going to be a month apart. so i think it will be july timing, basically, that we're aiming to ship sbt 1.0. so in the meantime, people can try sbt 1.0 by porting the plugins. so i've started porting a bunch of plugins myself. and if you find any bugs, just let us know. if you have ideas, let us know as well.
ow : eugene, it was a pleasure speaking with you today. and thanks for taking the time. i'm definitely looking forward to seeing the impact of your new team on our users' experience and learning and getting started with our tools more rapidly than ever before, i hope, on the lightbend tech hub , which you can access at https://developer.lightbend.com
as always, you can find out more about how lightbend helps some of the world's most admired brands embrace the next generation of streaming microservices and fast data apps with our reactive platform on lightbend.com. which is also where you can schedule a 20-minute introductory call with one of our representatives. so thanks again to eugene yokota, and have a wonderful day.
Published at DZone with permission of Oliver White, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.