The Changelog: Software Development, Open Source - Betting the company on Elixir and Ember (Interview)

Episode Date: July 18, 2015

Brian Cardarella joined the show to talk about the bet he's placed on Elixir and Ember to be the focus of his company.

welcome back everyone this is the change log and i'm your host adams dukovic this is episode 165 and on today's show jared is going solo all by himself talking to brianarella from Dockyard about betting the company on Elixir and Ember. Good show. We have three awesome sponsors, CodeShip, CodeSchool, and HipChat. Our first sponsor is CodeShip. They launched a brand new feature called Organizations. Now you can create teams, set permissions for specific team members, and improve collaboration in your continuous delivery workflow.

Maintain centralized control over your organization's projects and teams with CodeShip's new organization plan. You can save 20% off any premium plan you choose for the next three months by using the code THECHANGELOGPODCAST. Again, that code is THECHANGELOG the changelog podcast 20% off any premium plan you choose for three months head to codeship.com slash the changelog to get started and now on to the show welcome back everybody jared here i am fresh off of our trip to Denver for GopherCon 2015. I just want to give a quick shout out to all of our new Gopher friends and listeners. And trust me, we lined up a ton of Go-related shows in our pipeline. More on that later.

But we had tons of fun handing out t-shirts and shooting video interviews with everybody. In fact, if you're wondering where is the mellifluous voice of Adam Stack, he's actually heads down in the editing room this week, turning all of our raw footage from the conference into something awesome. But don't worry, Adam will be back next week and we will welcome Toby Knopp, who is the CTO of Mesosphere to the show. Stay tuned for that. But today, I'm joined by Brian Cartarella, who is the CEO of Dockyard. Dockyard is a web and mobile user experience consultancy in Boston, Massachusetts. Brian, thanks so much for joining me. Thanks for having me. So did I do you justice in the intro? Anything else you want to say about

yourself as a way of introduction? No, that's it. I'm sure we'll touch on a bunch of stuff yeah yeah absolutely brian i think i was thinking back of when you first came across my radar and in the open source world and i think it was with your client side validations gem yeah which uh for those who don't know was a ruby gem and i think it was probably only in the context of Rails, which purpose was to give us the ultimate kind of dry validations where you define them once in your models, and then we can actually traverse them down into, I think probably jQuery back then, into validations in the client side.

Right, so it will allow you to write them once. They'd export. Actually, there was some, before I even knew what transpilation was, it kind of did some Ruby to JavaScript transpilation. Really, really bad. Right. But it's interesting because client-side validations has kind of, was my first, like, use case for how I've been writing code over the next few years.

So client-side validations was what motivated me to want to get more heavily interested in client-side application development, and specifically something as complex as Ember. Yeah, I mean, I remember with the gem, because that gem came out, and it spoke to me very uh very tight like inherently i was like yes this is something that we need something that i know i needed um and so i started using it and i think i can't remember if i contributed back i definitely did some bug reports for you back in the day yeah and it seemed like uh a great goal but it just was a difficult thing for you to achieve. I think it was working

well, but there were a lot of issues. Did you struggle to actually execute on that idea? Well, the way that I wrote it originally, yes. So what client-side validations was doing under the hood was that it was trying to attach all these validation rules to input elements. And it was basing it off of string values. And then there was all this crazy rules in the back end. I'm sorry. I mean, within the library, not on the back end. And that's not even taking account of remote client-side validations the the uniqueness validator was a whole mess yeah but what i came to realize pretty early on and this is what i mentioned how i got became interested in ember was that client-side validations really needed a model to work against needed like a like a like a user model or something where you're actually going at specific values

rather than just trying to piecemeal all these values off of input elements. And so when I was building on client-side validations, I actually went down the path. I don't know if the branch still exists on the repo. But I went down the path of building out a very, very small and probably very poorly thought out client-side framework just for re-implementing client-side validations. And I got to the point where I'm like, this is crazy. I'll start looking at the backbone. Backbone didn't really interest me.

And that's where Ember was starting to get on my radar. And I went off in that direction. And then I realized that this whole, at least for me, the nature of server-side application development was really, I think, going to fall by the wayside. And client-side application development was going to be the next big thing. And so for someone that's running a business, I really wanted to get ahead of that curve and start establishing expertise there. So I kind of dropped client side validations off of my plate. Sorry for those that were using it. Um, I did do do, I did due diligence to try to find a replacement, uh, author. Um, I put the radar, I, I, I maintained

it for like six months. I asked people if they wanted to take it over, didn't get any takers. And so I finally sunset it. However, I think someone has taken it over now. I don't know if they're still working on it, but I gave them the RubyGems access, and they own the repo now. So hopefully it's found a good home. But yeah, that was always an interesting project from a technical point of view

of trying to get Ruby over to JavaScript, but also from technical point of view of trying to get Ruby over to JavaScript, but also from a point of view of, okay, I realized that this is the completely wrong direction for implementing this. And it's kind of taken me on this crazy journey to really becoming very well versed in client-side application development. Yeah. And I think as we, you know, as this conversation progresses, we'll probably take that journey a little bit. I want to also mention something that you do annually, which I've been a fan of over the years.

We just met, but I've been kind of following Dockyard to a degree because I'm also a consultant. I have a software company, employee number one. And I've always flirted with growing and not growing and the ideas behind it. So I follow other people that are doing that. I follow ThoughtBot to a degree and Dockyard. And just kind of like to watch what you're doing. And you make that really easy because you publish this lessons learned post annually,

which is kind of a year in review. It's kind of the entire life of your consultancy. And man, you're like crazy transparent in that post. Like I feel like you just kind of bear it all there. And I'm curious why you do that and just have you talk about that. So several reasons. First, I think it's just in my nature.

I tend to, I guess, wear my emotions and myself on my sleeve to a certain degree. I think anyone that follows me on Twitter kind of gets too much of that from time to time. I do a lot of Twitter complaining because I think that's the primary purpose of Twitter is just to like complain about things yeah yeah um and uh but the other reason which is probably a more um like politically correct thing to to say rather is that um when i was getting going with dockyard when i when i was because i was a freelancer, I worked in enterprise, I worked in startups, and I finally had it with that world. And I said, I'm going to work for myself. And I went and started freelancing.

And I very quickly realized that I've really traded one boss for like, you know, 10 or 20 bosses. Yeah, exactly. Yeah. However many you happen to have during a given year. So it's not really any more freeing. But I started getting more and more complex projects pushed my way. Stuff that required more than just me. So I reached out to a few people and we were working on a project. We worked well together.

We decided, okay, let's give this a shot and start a company. At the time, my LLC was horribly named. It was Dirty Water Development. For those that are from Boston. Yeah, yeah. So for those that are from Boston and that are Red Sox fans, that's the song that the Red Sox play. The Standells love that Dirty Water. Ah. Yeah.

It's a reference that went over everybody's head. Nobody got it, especially in light of when I was doing business under that LLC was when the Gulf oil spill happened. Oh, no. So everybody thought that this was somehow a tongue-in-cheek reference to the Gulf oil spill, which was not the case. So I think I realized very quickly that this was a bad name um and i'm a i i race sailboats i want to do something nautical so i i really do want a shipyard because i'm like oh shipyard shipping shipping software that makes sense right however there is a shipyard bear uh beer in maine and they own that domain name. And so Dockyard was the next obvious choice for me.

And to go back to your original question, when I was starting the company, I was starting from zero. I'd never run a company before. I grew up in a family. My father ran his own company. My grandfather ran his own company, but very different businesses. So I kind of got a sense of what it takes to, like the effort that goes into running a company. But as far as the specifics around running a software consultancy, I really had no one

to ask. I emailed a few people that were doing it. And what I realized very fast is that a lot of these shops are just BSing people. They're lying. They're saying everything's great, everything's awesome, because they feel that they have to put forth this image of excellence. And any time that there is anything that's negative about them out there, they fear that they're going to lose out on a contract,

they're going to lose out on an employee, they're going to lose out on anything. And so they just say, everything's great. Everything's awesome all the time. And I don't think that people learn from people's successes because I think success is fleeting. Success is very difficult to duplicate. It's usually time-based. It's luck-based. You happen to be fortunate enough that you were in the right place at the right time

and things worked out for you. That's, I think, the significant key to success sometimes. Effort and persistence is definitely part of that. But persistence actually just means that you're able to stick it out long enough so that you get lucky. Failures are super easy to duplicate. Failures happen all the time. And the way that you fail is probably very similar

to the way that I fail. And telling me how you failed will allow me to help cope with and avoid that particular failure or at least minimize the damage. And nobody wanted to talk about their failures. So I decided early on that if we can make it to one year, I actually, I think I did the first one after six months. And I want to share those lessons with people because I didn't see those lessons anywhere else. They were more of a cathartic thing for me. And I wasn't sure if anybody would like them. But they tend to get a lot of attention.

I think that annually they're definitely the most read blog posts, at least at the time when I publish them. We have some Ember posts that I think overall have gotten more traffic. But yeah, I talk about what went well, what didn't go well, what changes we can make in the upcoming year. I talk about how much money we've made. It's stupid not to talk about money, right? People don't like to share their revenue.

They don't like to share their rates. I don't know why. Maybe there's a really good business school reason not to do it, but I didn't go to business school. It's never hurt us in any way. And I really wouldn't want to run a company that we wouldn't be able to talk about these type of things. If we end up losing, if we end up doing worse one year, yeah, it will be embarrassing to

say that we didn't make as much money this year as we did last year. But that's, you know, ultimately that lies upon me and I need to own that. So do you, where do you draw the line? Do you have a line? Have you thought about that? Or do you just bear it all, whatever you feel like saying in those kind of posts? If it impacts one of my employees directly

or a former employee, it won't be brought up unless I've discussed it with them already. So a good example of that, I've discussed firing people. And one of the employees specifically was actually one of the co-founders of the company. And everyone hears this word firing, and they think, oh, that's bad. But it's what it is. We didn't lay them off. We didn't dismiss them. They were fired. And there's no two ways around it. And I discussed it with him. I said, I want to discuss

this within this given context in that, you know, perhaps in this case, I was wrong. I did not, you know, adequately set. So within that, for that specific person, I spoke about how what ended up happening was when we co-founded the company, we never set expectations upon people's roles and everything kind of fell upon me and I was getting frustrated. And I think the lesson learned there was that when you're starting a company, you should probably not even amongst your co-founders, not even split up ownership percentage until maybe six months in when you get a sense on like, okay, here's what people are really doing. Because beforehand, you can dream up like, oh, you're going to do this, I'll do that. And then reality sets in, people will really own up to what the responsibilities

are. You probably wait until that point in time before you decide, okay, this person's doing way more work than me, perhaps this, Perhaps my ownership percentage should be different than theirs. And that ownership percentage wasn't necessarily part of the problem there. It was more that I never really had expectations upon people beyond just development. And I should have set those expectations. So the failing was my failure. I think most of the firings that we've had at Dockyard have been my failure, with the exception of one or two. And that's me learning how to run a business. And I've

gotten much better at it. I've gotten much better at, I guess, being very clear with employees, like here is your role, here's your expectations, here's how you get to the next level. Or maybe I'm not as clear as I think I am. Perhaps my employees would think differently. But I think we're always working on it and trying to get better. So a good example of that is we actually created an RFP process for Dockyard. It's an open and public process. Anyone can view and, I guess, participate.

But we have one RFP that we've brought in so far. We actually have one RFP we've ever opened. If you go to Dockyard slash RFPs, I think it's plural on GitHub, you can see it. And this was around the career lifecycle of an employee at Dockyard, how they can move up, what are the expectations there, what incentives they have tied to bonuses. Because every year we actually, we just put this in place. So we would always have, everyone gets $1,000 at the end of the year, regardless of what they've done. If you were here for half the year, it's prorated to 50%.

And what we realized is that, hey, we might as well just increase everybody's salary by $1,000. This is not really an incentive. And so we determined a bunch of activities or events or things that people can be doing that will benefit DocuRare in some way. So if you go speak at a conference, if you speak at a meetup, if you're writing blog posts, if you're doing something that's helping the marketing of the company in some way, this will be calculated as part of a bonus at the end of the year. And it was never clear to people, like, what are those things? So we created this RFP in order to do that.

So crazy amount of openness, I think, is a good thing. And we're always looking for ways to be more open. Yeah. Well, I mean, just as an observer and somebody who, you know, casually observes your openness over the years, I appreciate it because I draw insights from your trials and tribulations and your successes. And and have kind of been able to track, you know, the struggles of of a software company. I guess now you've you guys have kind of focused in on, you know, web and mobile experience company, but you've traditionally been an engineering company that's bigger than I am, and thinking

should I try that? Should I not? It's fun from that perspective. I've also been following along technically with a technology bent, and just watching because I'm very interested in staying relevant and keeping up with open source,

which is Angelog's mission, helping people do that. And so I've watched you over the years make certain decisions. I think that the Ember decision was a while back. But then most recently, the one that kind of surprised

me, or maybe even just was impressed upon me that I remembered it, was in May of this year 2015 uh you guys kind of relaunched uh the new dockyard.com uh website which is very well put together by the way but uh you had a kind of intro post and in that post on your guys's blog you wrote this you said this new website is also built how we believe modern web applications should be built with ember js on the front end and phoenix on the back end um i want to focus on that decision kind of for the remainder of the show we were as i said we were kind of at gopher con last week

not kind of we were at gopher con last week and there was a halfway there yeah just you know actually we kind of felt halfway there because we were in the hallways more than anything else. But there was a great talk given by Kelsey Hightower, who's with CoreOS, where he said the kind of title was how they bet the company on Go. And how that bet paid off for them was kind of the content of the talk. And I don't know if you're necessarily betting the company on Ember and Elixir, but it kind of feels like that to a certain degree. It's definitely a bold move to come out and say, this is how we believe modern web applications should be built. I'm going to stop for a sponsor break before you respond to all that setup. We'll hear from one of our awesome sponsors and we come back.

I want to talk about that statement and whether or not it feels like you are betting the company. All right, put them away, put them back, put the books back on the shelf. You don't need them and learn to code by doing with code school. Code school offers a variety of courses,

JavaScript, HTML, CSS, Ruby, iOS, Git, and many, many more to help you expand your skills and learn new technologies. CodeSchool knows that learning to code can be a daunting task, and they've combined experienced instructors with proven learning techniques to make coding educational and memorable. It gives you the confidence you need to continue past those rough, tough hurdles that you will definitely face learning to code. CodeSchool also knows that languages are a moving target. They're always updating their content to give you the latest and the greatest learning resources. You can even try before you buy. Roughly one out of every five courses on CodeSchool is absolutely and totally free.

This includes instructor classes on Git, Ruby, jQuery, and much more, which allow free members to play full courses with coding challenges all included. You can also pay as you go. One monthly fee gives you access to every CodeSchool course, and if you ever need a breather, take a break, you can suspend your account at any time. Don't worry, your account history, your points, your badges,

they'll all be there when you're ready to pick things up again. Get started on sharpening your skills today at CodeSchool.com. Once again, that is CodeSchool.com. All right, we're back. Brian, does it feel like you're betting the company on Ember? And does it feel like you're betting it on Elixir? I don't think you can ever do that in software, right? Because there's always going to be something new.

And you're just one blog post away from changing your mind. From a new bet, yeah. Yeah, like, oh, we decided. We went with Framework, JavaScript, 10.0, whatever. Right. But I, so the reasons why why we started as a rails consultancy and i i've been working with rails since before 1.0 um my my i think my true talent still lies with rails and ruby i'm probably the most experienced of all the of all the technologies

i have worked with i'm still the most experienced in Ruby and Rails. The reason why we as a consultancy decided to move away from that was because Rails has become a commodity at this point. It has accomplished what it set out to do. And I think I either touched on this in the blog post you referred to or perhaps in our annual blog posts at the, uh, at the end of last year, um, we found that we were not able to get the rates that, uh, we want to be getting with Rails work. Uh, the market is becoming, uh, oversaturated with beginners that, and because Rails has done so well, what it says to do beginners can really get done maybe 80% of what a senior developer can do. It's that 20% that you really need somebody.

It makes all the difference. But for getting an application up and running, that's fine. Scaling the application, different question. So I started, and this is where we were poking around with Embraer for a period of time. And I realized that, you know, this is perhaps a better business move to move over to a client side application. If this is the way that we feel that the technology is going to swing, then if we can establish ourselves as an expert early on, then maybe we can do something similar to what ThoughtBot or HashRocket or Pivotal

did in the rail space, but we can do it with Ember. And to a certain degree, I think we've accomplished that in the Ember world. We have a pretty good reputation there. Our brand is pretty well recognized. We have a pretty good team. And I think for the most part, we're pretty well respected in that space. However, I don't think that Ember is ever going to rise to the size that we're looking at. Is the world big enough to be sustainable for just that kind of work? I think the JavaScript world is definitely big enough. I think that the JavaScript framework world, though, is too fragmented. And Ember's piece of that pie

is always going to be decent, and perhaps it may sustain a consultancy a little bit larger than ours. We're at 19 right now. It could probably sustain a consultancy around 30. But we're interested in really growing, getting big. So I don't think that Ember alone can do that. We're continuing to build out backends with Rails.

And because now we have this super fast client-side application that's running and routing between pages felt instantaneous, the response time of the application, especially when we got into production and started going a little bit under scale, any slowdown in response time, any delay was really magnified under those conditions. So I'd always been following Elixir. I really respect Jose Valim.

And it always seemed very interesting because it gave like this Ruby-like syntax on top of a technology that I've always been peripherally very, very interested in, which is Erlang. A friend of mine who worked at Bas basho uh chris micklejohn uh he has been talking about for a very long time uh he's like everyone you gotta try early anxiety i i looked into it i'm like um i'm i guess i'm a bit of a syntax knob i think ruby kind of ruined me in that way and i saw the syntax like, oh, I'm out. I can't do this.

I just don't feel like it. It's such a... I just don't feel like it. Yeah, I just don't feel like it. It's such a weird thing to say that the syntax turned me off. And I think some people will point and laugh like, ah, that's stupid. But it was true. I think a lot of Ruby people tend to think that way. Or Ruby has kind of like ruined our mind.

Like we desire a good syntax. And that's the starting of the conversation for us when it comes to technology. Like this is something I'm living in a lot. Like how is the syntax? Is this going to look ugly? Is this going to be a pain in the butt? Am I going to be able to read it? Am I going to be able to teach it?

And Erlang's syntax was, I think it's based on Prolog maybe. It was just, I don't know, crazy weird. So, but when Elixir, I think was getting close on Prologue, maybe. It was just, I don't know, crazy weird. But when Elixir, I think, was getting close to 1.0, I revisited it. And Dave Thomas, I think around the same time, published his programming Elixir book through PragueProg. And he was one of the authors that got me interested in Ruby in the first place. So I, I bought the book.

I don't download books. I'm not, I guess, I don't know, maybe I'm getting too old, but I like holding a book. I have a hard time reading PDFs. And I read it.

It's actually kind of universal. Like there's really, yeah, there's been recent studies, even on like millennials or whatnot and teenagers today where, you know, we thought ebooks were going to like take over and just make make paper books irrelevant but it finds they're just

kind of augmenting they're just another form of transport people actually do like holding things i i agree with you of course yeah that that could be me also getting ancient but i think there's some studies behind the fact that that's actually i I think people do have, there's something about the physical medium and the holding of it that's, I don't know, it's real. Anyways, go on. All right, I'm not alone then. You're not alone, definitely. But I read the book. It's excellent.

And in it, Dave even spoke about how he's as excited about Elixir as he was when he first started doing ruby so that got me hooked into it i respect dave thomas a lot uh and the more i read in the book the more i'm like wow this really makes a lot of sense to me because i was never i was never a developer who really got into the design pattern craziness. And I actually found that design patterns to a certain degree were being overused, overexploited, were misused quite a bit, and actually tended to do more damage in certain projects where you had, like, a lot of beginners were just taught patterns, like, do this pattern. And that's what beginners get, right? They have like here's my rules but they would just the pattern would

become the hammer yeah like which pattern am i going to use here instead of like how do i solve this problem like which exactly use so we as a shop we inherited projects from consultancies or from freelancers or from existing teams and we saw this all the time, and it became actually very difficult to follow and build off of properly. So what was nice, not to say that Elixir or LINE doesn't have patterns, but functional programming feels far more simplistic than object-oriented programming does. Object-oriented programming, I think, obfuscates a lot of what's going on,

whereas functional programming is like, literally literally here's the data flowing through and you can just follow it. And for me, I really kind of clung onto that concept and oh by the way, it's significantly faster. It orders a magnitude faster than Ruby. It doesn't consume nearly as much memory. It's already set up for multi-core consumption and distributed code. So all those things were really nice to have as well i've never really done any distributed application development before i can't say that i have done real luxor distributed application development yet other than some of

the examples in the preg prog book but to know that i have this tool under my belt that has 30 years of of like of experience and building out huge distributed systems um is really nice to have and definitely something that i want to explore more in the next year well let me ask you this i mean i've i had similar interest in elixir and we've had um chris mccord on uh recently who's the author of the phoenix framework and he kind of did a good job of selling uh the idea that it's something worth looking into and um for me i'm still very interested in it but where i kind of like anytime there's something that's just built on top of another language you know it just feels like it's always going to be like a hobby or it's it's i don't don't know. There's something like, it feels like the longevity is not guaranteed. Whereas like Erlang itself,

you know, was built way back in the eighties, I think, or I don't know when it started, but way back in the day, and it's been around for years and it's so mature. And, um,

you know, I, I respect Jose Valim quite a bit. It's just as like you do. Um, and so this isn't a knock on him or his idea or anything, but does it, did it feel like it's just a you do um and so this isn't a knock on him or his idea or anything but does it does it feel like it's just a bolt-on to a thing that already you know that's established or does it feel like it's its own thing it definitely feels like it's its own and also

it's from what i've heard at um i think it's called erlang, which is like the big Erlang conference. Oh, okay. I think there's actually a consultancy, but I think they have a conference annually. I think you're right, yeah. And I could be wrong. Someone may say, you're wrong, Brian. But I seem to... Erlang Factory pops in my head.

But anyway, I heard that there's a growing number of Elixir attendees, like a significant number of Elixir attendees that are being attracted to the conference. Because Elixir is like this gateway drug. And Erlang has always had kind of a, not a closed community. It's definitely not closed. it's been more of an academic language and used for those purposes than Ruby or JavaScript or Python have been used for web application development. And now Elixir has kind of thrown open the doors to the masses, right? It's this very approachable language built on great technology. And I wouldn't be surprised if more people are doing Elixir than are going to be doing Erlang. Yeah, you're going to be doing Erlang.

I don't think that the analogy of like Elixir to Erlang is the same as JRuby to Java, JVM. I don't think that, I never dreamed that JRuby would ever overtake Java world in any way. It always kind of felt like this, and no knock against the JRuby team because those are, like Charles Nutter, super smart guy. And like the way that they built that out is amazing, but it always kind of felt like this halfway world

between Ruby and Java, whereas Elixir definitely feels like its own thing onto itself like that you not only get uh this nice uh language and i say language with quotes around it because it's very more of a um it's like a parser and then most of elixir standard library is written in elixir itself even certain things like if statements are written in elixir because it will just parse it and then it gets access to the uh to the uh to the ast and that gets exported to beam and this is uh so you can augment the language any way that you want which you know you know, can be good or bad. In fact, in Chris's book, Chris McCord's book, The Metaprogramming for Elixir book,

he sets out some rules of macro development. And like, I think the first one was don't write macros. And the second one may also be don't write macros. And so it's, you know, macros. And then he shows you how to write macros after that. Yeah, the rest of the book is writing macros. But it's, you know macros after that yeah the rest of the book is writing macro but but it's you know it it's one of those things that um it's a very powerful feature that is core to elixir but do you really want to go down the road of building out like all these

language features they'll be non-standard people that are joining the project won't know what it is versus perhaps working with the language itself. But if you need to do something, if you need to grasp that power, it's there if you need it. Another aspect of Elixir that, you know, just questions I have around it, especially from the perspective of what you said with Dockyard, is you're trying to grow a large consultancy. Is access to people who are good at it, you know, perspective hires for you or developers that could, you know, build your back ends out.

Yeah. Has that been an issue or do you see that being an issue down the road? For hiring Alexa developers? Yeah. Alexa specifically? Yeah. Or just Ember? Elixir specifically, yeah. We have had, I wouldn't say that anybody in the shop right now is a dedicated Elixir developer. Okay. Majority of our contracts that over the past year have come our way have actually been specifically client-side application development with Ember.

I'd say the most common case would be that... It's actually interesting because now that we've done so well in the Ember world, I think a lot of clients that come to us actually don't know that we can do backend development. And so they've actually gone out in many cases, hired a separate team to do the backend. A lot of the time it's Rails or something else. And I asked them why they did that, why they just come to us. And they're like, oh, we thought you guys were just Ember. And so we're hoping to establish ourselves in the same way that we did with Ember from a marketing perspective. And that's going to require us to start releasing open source for Phoenix and Elixir,

start really blogging about our experience with it, start getting some example client projects, case studies on how perhaps we rewrote a particular backend that was preexisting in Phoenix and what type of advantages and disadvantages were there. That's going to take some time. But I think that anytime a consultancy engages heavily in a new technology and gets involved with the growth and community of that technology, they put themselves in a really good position to benefit from it if that technology ends up doing well. I think Ember's done well in Ember 2.0, especially Ember 2.1, because 2.0 is more like the transition. We remove all the

deprecations from 1.13. 2.1 is when we get a lot of nice new stuff. That's going to, I think, see a lot higher rate of adoption because the barrier of entry to ember is being knocked down all the time with every new release they're they're just making it easier and easier to get into ember so now ember cli is actually it's we hit the they did lockstep versioning so we're at 113 we went from 0.2 to 113 overnight um but the barrier of entry for ember is getting smaller so ember is going to become more adoptable. And because Dockyard is in a good position, we'll benefit from that. I think that Phoenix and Elixir are really good technologies.

And as especially the closer Phoenix gets to 1.0, we'll see an increase in momentum. And if we can position ourselves in such a way that, oh, Dockyard is a good consultancy for building out Phoenix applications, then we'll benefit from that as well. So we kind of have this two-pronged approach. We're establishing, I guess, like you said early on, betting on a client-side application framework and betting on a backend technology, both of which are members,

not exactly new at this point, but Phoenix is definitely new. Yeah, I mean, back, I can't remember when it was, when you decided or when you posted about Ember, you know, your guys' new focus on Ember. I remember reading that post and thinking, I had tried Ember at the time

and I was dabbling with the different, you know, clients at NBC things as well and just trying to see like, where do I go, where do I invest myself as a developer to produce good quality product and to make myself a viable person in the next five years or whatever. And to me, I was turned on to Ember because of the people behind it. They come from the Ruby land and all that, and I respect Ye i respect you and we've had him on the show multiple times um ember data was so immature at the time that it felt like ember was mostly promises back then like good promises but like there wasn't much substance behind like i could tell it man there's so much work to do before this is awesome um and then i kind of looked into angular and angular was more

productive immediately and so i had like a six month love affair with angular yeah and i kind of you know kind of faded on that a little bit but um now with ember 2.0 and it seems like ember's finally here but is that is that safe to say like embers now arrived and it wasn't really like you guys probably had a lot of shoring up to do around it back then that embers been slowly arriving for a while now right it's like this it's like this massive ship that's coming in the harbor yeah being pulled along by a tiny tugboat or something i don't know that might be a bad analogy but yeah it does. I've said several times that I actually think that Ember 2.0 is really Ember 1.0 in many ways. Like 1.0 being like the, hey, this is the direction that we want to go in.

Ember 1.0, I think that they reached some place of stability and they wanted to get a 1.0 out there to start seeing adoption and use cases come in. And so the use cases have really driven the direction of Ember. I think it will continue to drive the direction of Ember, but it significantly drove the direction of Ember between 1.0 and 2.0. While I'm going to say it was mostly semantically versioned uh yeah between 1.0 and 2.0 um i would debate on whether or not it was 100 but i think for the most part amongst most open source projects it was probably the closest to being i guess perfect semantically version as you can get but um the direction changed quite a bit or or they at least found the right use cases for pushing in one direction versus the other.

I think that 2.0 is really going to be the version that people look at and say, okay, this is something that we can build something in. This is something that is competitive with the other frameworks that are out there. We have the fast rendering engine with Glimmer. We have the client-side application tool with Ember CLI. We're reducing, I shouldn't say if we, but core team is reducing the barrier of entry by just cutting out the fat. The innumerable, many of the innumerable tools

that were in Ember were just removed. So why have all these array prototype stuff if you can just depend upon Lodash? Maybe a better citizen in the JavaScript community leverages the tools that are out there rather than rewriting them. Controllers are still in 2.0

but they've really been kind of mums the word on controllers. But object controller, array controller have been pulled out. It's just going to really simplify the amount of things people have to learn within Ember. What I will say, though, is that it has also increased the barrier of entry from before you ever get to Ember. So now people need to be an effective Ember developer or the quote unquote Ember way of doing things. You're going to have to really understand ES6, ES7-ish type stuff.

ES6 modules. You'll have to, if you want to debug certain stuff, you're going to have to start understanding how the build process works for Ember CLI. So I think the complexity of knowledge has been shifted off of the framework and more to the tooling. And hopefully that will start to simplify and normalize, especially as browsers begin to implement many of these ES6 features

and Ember CLI itself becomes, you know, built out even more. Yeah. Yeah, well, we're definitely seeing the maturation of Ember and I think even the maturation of client-side MVC. One thing I want to talk about, we are going to take our second sponsor break. When we come back, I want to talk about,

you guys said this new website's built how we believe modern web apps should be built with Ember and Phoenix. I want to talk about the technical aspects of DocuRare.com because traditionally in the last few years, single-page apps or client-side MVC frameworks, where they've really shined is dashboards, heavily interactive visuals, anywhere where you're chilling on the same page for a long time and you're just loading new data in. But where they haven't is on content sites. It's kind of been the web app versus website debate. And the interesting thing about Dockyard.com is, I mean, it's effectively a content site and it's not a dashboard. It's not a rich, I mean, it's a rich UI, but you know what I'm saying.

And so like, it's not an application. It's not an application. It's a website, I mean, it's a rich UI, but you know what I'm saying. Yeah. And so like, it's not an application. It's not an application. It's a website. Right. But, and yet you still think that Ember and, and Phoenix and that separation is the way that these should be made and built. So I think there's been some advances. You mentioned Glimmer and some other things.

I think we'll talk about some of the technical details of the website when we get back. HipChat is a game changer for team communication. It helps you and your team get the information you need faster than email and reduces meaningless meetings. Teams that use HipChat are able to make faster decisions and get more work done with group chat, video chat, and file sharing. HipChat is a great solution for distributed teams by letting you take the office with you no matter where you go iphone android mac os it's all there hip chat is

easy to use and gets everyone working in real time and right now hip chat is offering listeners of the changelog 90 days of hip chat plus totally free. Get premium features like unlimited file storage, unlimited message history, and guaranteed support totally for free for 90 days. Visit hipchat.com slash changelog. Again, that's hipchat.com slash changelog. Get your team started using HipChat Plus today. Go and check them out.

All right, Brian, let's talk about the technical details of Dockyard.com, how it was built, how Ember and Phoenix work together, and take me through it, deployment, all the goodies, all the technicals. So the previous, I'd say two or three iterations of our

website were built in Rails, and we were no longer really doing Rails. I think that if we're in our blog posts, in our open source, in our presentations telling people that you should be using this technology, we kind of have to dog food it. We have to walk that walk. We have to say, okay, we think you should be using this technology because we use it rather than just maybe using middleman or some sort of static site generator. Yep. So we set out to use some really edge technology

in the Ember world, specifically this new thing that was just released at the time called Fastboot. Actually, I don't even think it was like production ready released. So Fastboot was or is Ember solution server-side rendering of your Ember application for the purposes of SEO. It was built by Tom and Yehuda, and they were sponsored by Bustle, which is a company I think in New York, I want to say. I may be wrong. But anyway, and they've actually leveraged a lot of the work they did on Fastboot to build out the Glimmer rendering engine in Ember. So it had some very high impact benefits doing that particular feature. So Fastboot would actually take your Ember application and boot it up in Node.

And so when you hit the request, it will render out your Ember application server-side, serve it up to you as a server-side rendered application, and it would be there. And then Ember would launch in your browser. And I think the process they called it is hydrate the DOM. And so it would just kind of realize that this is already an Ember-generated application, and we're just going to kind of latch onto it and take over so we don't have to redo everything. That was the theory.

In reality, what we saw was that, but FastBooth at the time had some really ugly uh memory leaks in it and so we like most memory leaks they did not come up until after a production right talkcare.com uh always benchmark your applications i guess or stress test them. All right. But we were so excited to get it out. So we had to pull back. And I think actually Dockyard, someone may say, hey, we have one up before. But I'm pretty sure that Dockyard.com was the first production fast food application out there.

It may still only be one of the only ones out there. And what we've done to solve the memory leak issues was we're still using Fastboot, but when we deploy a new application, it will actually send it to our backend server as well. We use our sitemap to walk through and generate all the static templates with Fastboot. And then those static templates sit behind NGINX. NGINX serves them up through its cache. And so we get the benefits of the SEO, but it's not as smooth as Fastboot would be. But it's still a very fast website. Even though we're still using Ember, but it's still a very fast website. Like even though we're, um, still using Ember.

And that was a complete, oh, people always had like, oh, Ember's so fat, uh, Ember's slow to load. Right. If you go to docker.com, I think on average it loads up in like 0.75, uh, 0.75 seconds, uh, which is pretty quick for a client set application. We were able to shrink down our asset size, I believe to close to 200 down our asset size, I believe, to close to 200K, somewhere around there, which is pretty reasonable. And our blog actually sits in a database.

And so when you hit the blog, this is being served up by Phoenix. And it's, I believe, almost all the pages. The whole page or just the data? The whole page? All the data. So if you were to, if you look at your network tab, you can see the data coming in. So this is all being served up by, all of our data is being served up by Phoenix. I think most of the content pages actually sit in the database, like all of our team members sit in the database. So we have Phoenix acting as this dumb API that's just being serving up data,

and then Ember is our client side. And we haven't heard any drawbacks from doing it this way. We haven't had any people saying like, oh, we get the occasional like, oh, you should support non-JavaScript browser type troll stuff, but we don't really pay attention to that way of thinking anymore. We get the occasional, like, oh, you should support non-JavaScript browser type troll stuff. But we don't really pay attention to that way of thinking anymore. But it's a very fast website. Like, switching between pages is very fast.

And that's what I user experience of any application. So we chose a framework and a backend technology that gave us the best speed as well as being, I think, fits best into our sensibilities as engineers. Yeah. So when you navigate pages, I mean, there's no hashtag in the URL or anything. You've got your URLs are clean. Is that still, Ember is doing all that routing, correct? Correct. So is that just a feature of newer browsers? Does that work on everything?

Yeah, so I think we might be using auto-location, actually. And in Ember, auto-location will detect whether or not you have the history API, whether or not that's available to your browser. And if it does, it'll give us this nice, clean URLs. If it doesn't, it'll fall back to the hashtag okay go to the hash hash version right i think like ie10 below uh i think like ie9 ie8 stuff they may fall back but most evergreen browsers now i believe are all are all evergreen browsers are actually uh uh history api so what is auto location is that a library Is that part of Ember's router will decide what type of URLs it's going to

generate through its links. Yeah. I just found the page. We'll link that up in the show notes. It says Ember auto location. We'll select the best location option based off browser support with the priority order history and then hash and then none. Yep.

That's pretty cool. Awesome. So you're kind of using a modified fast boot or you're using a... We're using regular fast boot, but we're not allowing public access to it. Gotcha. So Nginx is only serving up

our cache-generated templates right now. You kind of crawl it yourselves on deploy type of a thing. Correct. Okay. So it's a little bit of an engineering you know what we would call maybe a hack to a certain degree until fastboot you know can and do it on its own or it's just in service of even faster boot it was a hack to get us around the memory leak issue however as of this past monday stefan penner on the core team believes he may have closed out all the remaining memory leaks on Fastboot.

So he wants us to move Dockyard.com over to regular Fastboot. I told him we're probably going to do that sometime in August. That would be definitely interesting. Gosh, what else about this?

So just perusing it myself, it definitely loads fast. I mean, initial load is slower, but it's still pretty fast. And then obviously your page navigation is super fast. And I know you're using it kind of as like we're investing in these technologies, we're going to use these technologies. Is it possibly over-engineered for what you guys are trying to accomplish with your website? It's an over-engineered content site for sure. Yeah, okay.

If someone approached us and said, we want to build a content site. You wouldn't build it this way. No, not unless they had a very specific reason for doing so. Yeah, that's kind of like where I've, where I've been is, you know, I'm trying to see like, when does it become the way to build everything?

Right. I still feel like there's still use cases and there's still, what are you trying to accomplish? And let's build the website the way that makes the most sense for your, for your goals. And I think you guys have done that with this because you're, you know, because you are a company that does this and you want to help you're

kind of pushing the bleeding edge to a certain degree with helping out with fastboot helping out with these things and showing off what you guys are capable of in a good way um but probably you know as far as about time and money and all that for the for the goals of a content site still unless it has some specific needs, you know, a static site generator or something simpler is probably still the way to go at least, you know, July 2015. Agree with that? I think so for the most part.

I do think that there's also something to consider around those that don't have as great Internet access as we do in the United States. Or if I'm not sure where you are, but on the East Coast, I think we have the best, at least the shortest distance to everything. And if you're somewhere in Africa and you're reading a very content heavy site, do you really want to have to re-download the entire page on every single click? Or is it going to be more performant to just download perhaps the data set? So I think context matters. And the concept and architecture of a client-side application really works well for many use cases that could be content-driven sites. But as far as a shop site like if we

weren't an ember shop then we probably wouldn't have done that yeah i feel like we're you know we're breaking down barriers like the seo barriers broken down and you know to a certain degree the url cleanness barriers started to be broken down and yeah context always matters um so i could see where as long as you get i mean sometimes on a slow connection you don't get that official you know that initial download never happens and then you're like well um so it it's give or take but uh awesome anything else about ember or elixir or yeah i'll say i'll say go ahead say one last thing about ember. Another really nice feature that's coming soon is that a developer from LinkedIn is working on this. We will have the ability to create even smaller

versions of Ember pretty soon. Right now with ES6 modules, we're doing import statements at the top and we import a specific module. What's going to be coming pretty soon through Ember CLI is the ability to walk that import tree and only transpile the specific modules that we're using. So right now when we, when we import Ember, we get the entire Ember thing, right? And in the future, we're going to say like import Ember dash get, import Ember dash component.

If we don't use like the evented service for whatever reason, then we won't have that in our final asset output. And so our footprints can be significantly smaller. So people's issue with the size of Ember should pretty much be going away soon enough. That's great. Then the size of your asset bundle kind of scales up with the size of your application. How much of the features are you actually using?

You know, you get bigger and bigger, but for those people that just want to take advantage of the routing and the other niceties, you have smaller bundles. That'll be excellent. Any idea on timing around those kind of progress? I think that's a when it's done feature, but I know that they're actively working on it because it's a big concern for

LinkedIn. Right. Awesome. Well, let's let's take a moment to do our awesome closing questions. Got two of them for you here. And the first one is one that we ask quite often is that if you had to pick somebody out there,

you could have more than one if you need to. But if you had to pick a programming hero, somebody to look up to, who would that be and why? I'd probably pick a, he just left Dockyard, but Robert Jackson. He is a core team member of Ember and in the year and a half ish time that he was at dockyard uh the guy just super impressed me with his ability to not just get things done but also remember things like he's got like a um he can recall i i like when i work on code i'm familiar with what i worked on and i kind of go if i don't touch it for a month got to go back and kind of familiarize myself with it. He just immediately remembers exactly what it was.

He can tell you everything. That level of recall was just super impressive. I think he was excellent to work with. Very cool. I'm definitely going to link him up in the show notes. I had never heard of Robert Jackson, so I'll be checking him out. I think he's the number one committer on Ember right now. So he moved on from Dockyard.

Where is he moving on to? Does he have plans? I think the name of the company is Aptable. I'm not sure if I'm really... I think they brought their product out, but they're, they're kind of doing Roku for healthcare. So like a big problem with healthcare companies on Roku is the

compliancy. Yeah. And I think that they're trying to solve that problem for platformers of service, uh, healthcare applications. Yeah, that makes sense.

That's a, uh, that's a big market. If you can get it. Cool. Uh, next one is what's on your open source radar? We've obviously talked a lot of different open source projects and feel free to mention

ones that you're up to personally or the dockyard's doing. But if you had a free weekend and you were going to just play with something new and exciting that has your eye, what would it be? I actually have to do the opposite I have to stop playing with stuff because I got I got like developer ADD and I get onto too much stuff

I mean that is probably part of the reason why I push my company in the direction I have rather than taking the safe bet let's keep doing Rails I mean if there's something I want to do more stuff with distributed code and Elixir. I don't have a specific library for that, though.

Cool, cool. Speaking of Dockyard and Elixir and open source, I noticed you guys have a library out there for testing Phoenix JSON APIs called Voorhees. Any other cool open source GitHub projects that you or Dockyardyards up to that you want to, uh, give a shout out to. I have like a 25% completed elixir. Uh, they're called applications and elixir, they're not libraries.

Okay. So I think that that's a, that's a, uh, uh, Erlang term. Okay. Um,

which still feels a little weird to me, but I have one that, it's kind of like a fixture library for, um, well, for fixture library for, well, for, for Phoenix, well, Phoenix applications,

Elixir applications. It's going to have a very simple DSL for declaring fixtures. Got a name for it. I just have it called fixtures right now. Yeah. It's not very creative. All right, cool. Yeah, it's not very creative. All right. Cool.

Well, distracted searching for it on your GitHub. Is it still? You're working on it. That's only 25% done. You got to get to at least, you know, 60% done. Then you put it online, you know. Yeah, and then I only bring it to about 70% of it. And then I move on to something else.

Yeah, then you find a maintainer. Well, Brian, thanks so much for joining us. I really enjoyed picking your brain on all these things. How can people reach you out there on the internets? Probably don't want to follow me on Twitter, but you want to check out at Dockyard on Twitter. We put a lot of our stuff on there. We actually just finished. So we hosted a conference, Wicked Good Ember Conf, in June. yard on twitter okay uh we put all our stuff on there we actually just finished so we host

we hosted a conference wicked good ember comp in june we had uh about 200 people there we're on an island so we we talk about that experience we've uh mentioned our blog post through our twitter account uh that's probably the easiest way to kind of just catch up with what put them up too cool very cool well as always links are in the show notes uh you can find those at changelog.com the easiest way to kind of just catch up with what I'm up to. Cool. Very cool. Well, as always, links are in the show notes. You can find those at changelog.com slash 165. We also want to thank all of our members and our awesome sponsors for making this show possible. This week's sponsors are CodeShip, CodeSchool, and HipChat.

As I said before, we have a bunch of awesome shows in the works. Some of those are Mesosphere, Prometheus, NEJS Conf, Crystal, BoltDB, Editor Wars, and a whole lot more. So if you haven't hit that subscribe button yet, why not? Remember, we have an open inbox on github.com slash the changelog slash ping. Give us a shout there with your show ideas, entering projects that you have or that you've created or just say hi

we love hearing from you I want to announce that we're going to become a crystal development shop oh breaking news yes breaking news crystal is the new hotness very cool it does look like a cool technology I'm excited for that show we're very interested in it

that should be a good one but until next time let's go ahead and say goodbye I'm excited for that show. We're very interested in it. That should be a good one. But until next time, let's go ahead and say goodbye. See ya. Oh, goodbye. I'm out.