Betting the company on Elixir and Ember

Welcome back everyone, this is The Change Log and I'm your host, Adam Stachowiak. This is episode 165 and on today's show, Jared is going solo all by himself, talking to Brian Cardarella from Dockyard about vetting the company on Elixir and Ember. Good show. We have three awesome sponsors, Codeship, Code School, and HipChat.

Our first sponsor is Codeship. They launched a brand new feature called Organizations. Now you can create teams that 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 TheChangeLogPodcast. 20% off any premium plan you choose for three months. Head to Codeship.com slash TheChangeLog to get started and now onto 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 Cardarella, 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, which 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 like 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 like 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. And I remember with the gem, because that gem came out and it spoke to me very, very tight, like inherently.

I was like, yes, this is something that we need, something that I know I needed. 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.

And it seemed like a great goal, but it just was a difficult thing for you to achieve. I think it, I think it was working well, but there were a lot of issues. Did you struggle to actually like execute on that idea? Well, the way that I, 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, you know, crazy rules in the backend.

I'm sorry. I mean within the library, not in the backend. Right. And that's not even taking into account of like remote client-side validations.

The uniqueness validator was a whole mess. 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. It needed like a, like a user model or something where you're actually going against 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, if the branch still exists on the repo, but I still went down the path of building out a very, very small and probably very poorly thought out like client-side framework just for re-implementing client-side validations. And I got to the point where like, this is crazy. I'll start looking at 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. I did do due diligence to try to find a replacement author. I put the radar.

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 gave somebody, I don't know if they're still working on it, but I gave them somebody the Ruby gems 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 the 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 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. 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 watch. I like to watch what you're doing and you make that really easy because you published this lessons learned post annually, which is kind of the 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 like complaining about things. Yeah.

But the other reason, which is probably a more, like politically correct thing to say, rather, is that when I was getting going with Dockyard, when I was, so I was a freelancer. I work in enterprise. I work in startups. And I finally had it with that world.

And I said, I'm going to work myself. And I went and started freelancing. I very quickly realized that I've really traded one boss for like, you know, kind of 20 bosses. However many you happen to have during a given year.

That's not really any more freeing. But I started getting more and more complex projects pushed my way. So that required more than just me. So I reached out to a few people and we just thought we were working on a project.

We've 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. So for those that are from Boston and that are Red Sox fans, that's the song that the Red Sox play at the Sandells. Love that Dirty Water.

Yeah. It's a reference that went over everybody's head. Nobody got it. Especially in light of when I, when I was doing business under that LLC was when the Gulf oil spill happened.

Oh no. 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. And I race sailboats.

I want to do something nautical. So I really wanted shipyard because I'm like, oh, shipyard, shipping, shipping software. That makes sense. Right.

However, there was a shipyard beer beer in Maine and they own that domain name. And so Dockyard was the the next, next obvious choice for me. And to go back to your original question, I started when I was starting the company, I was starting from zero. Right.

I never run a company before. I grew up in a family. Like my father ran his own company 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 gonna 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 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 are 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 it and 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/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 a thousand dollars 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, this, we might as well just increase everybody's salary by a thousand dollars.

This does not really incentive. And so we determined a bunch of activities or events or things that people can be doing that will benefit Dockyard 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 I've kind of been able to track, you know, the struggles of a software company, or I guess now 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 like thinking, should I try that? Should I not? You know, and so it's fun from that perspective.

I've also been following along, you know, technically with a technology bent and just watching because I'm very interested in staying relevant and, you know, keeping up with open source, which is, you know, Aglug'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, you guys kind of relaunched the new dockyard.com website, which is very well put together, by the way. But you had a kind of intro post.

And in that post on your guys' 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. I want to focus on that decision for the remainder of the show.

As I said, we were kind of at GopherCon last week. Kind of. We were at GopherCon last week. And there was a talk 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. I don't know if you'd necessarily be 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 when 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.

Code School 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. Code School 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 Code School is absolutely and totally free. This includes instructor classes on Git, Ruby, jQuery, and much more, which allow you 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 Code School 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 and 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. Ryan, 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 a framework, JavaScript 10.0, whatever. So the reasons why, we started as a Rails consultancy. And I've been working with Rails since before 1.0.

I think my true talent still lies with Rails and Ruby. I'm probably the most experienced 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 decide 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 post at the end of last year. We found that we were not able to get the rates that we want to be getting with Rails work. The market is becoming oversaturated with beginners.

And because Rails has done so well with what it set out to do, beginners can really get done maybe 80% of what a senior developer can do. It's that 20% that, you know, makes all the difference. But for getting an application up and running, that's fine. Scaling application, different question.

Right. So I started, and this is where we were poking around with Ember for a period of time, and I realized that 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 Hash Rocket or Pivotal did in the Rails 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 Rails does. Yeah, 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 were 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 that I have this tool under my belt that has 30 years of experience in building out huge distributed systems is really nice to have and definitely something that I want to explore more in the next year. Let me ask you this.

I mean, I have similar interests in Elixir. We've had Chris McCord on recently, who's the author of the Phoenix framework. And he kind of did a good job of selling the idea that it's something worth looking into. And 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, I 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 80s, I think, or when it started, but way back in the day and it's been around for years and it's so mature.

And, you know, I respect Joe Legally quite a bit. It's just like you do. And so this isn't a knock on him or his idea or anything, but 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?

Yeah. It definitely feels like it's its own. And also it's, from what I've heard at I think it's called Erlang Factory, 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, but 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, yeah, going to be doing Erlang. Because 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 I know not against the JRuby team because those are, like Charles Ner is a super smart guy. And like the way that they built that out was 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 you not only get this nice language, and I say language with quotes around it because it's very more of a, 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 AST and that gets exported to Beam. And this is, so you can augment the language any way that you want, which, 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, these macros.

Yeah, the rest of the book is writing macros. But it's, you know, it's one of those things that 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 that will be nonstandard? People that are joining the project won't know what it is versus perhaps working with a language itself. But if you need to do something, if you needed 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, for the perspective of hires for you or developers that could, you know, build your backends out. Has that been an issue or do you see that being an issue down the road? For hiring Elixir developers? Yeah.

Elixir specifically, yeah. We have had, I wouldn't say that anybody in the shop right now is a dedicated Elixir developer. 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, 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, right?

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 transitional removal of 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 just making it easier and easier to get into Ember. So now Ember CLI is actually, it's, we hit the, they did lock that version, so we're at 1.13. We went from 0.2 to 1.13 overnight.

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 where establishing ourselves, where, I guess, like you said early on, betting on a client-side application framework and betting on a backend technology, both of which are, Ember's not exactly new at this point, but Phoenix is definitely new. Yeah. I mean, back, back, I can't remember when it was when you decided or when you posted about Ember, you know, your guys's 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, client-side MVC things as well and just trying to see, like, where do I go?

Where do I invest myself as a developer to, you know, to produce good quality product and to make myself a valuable person in the next five years or whatever. And to me, I mean, I was turned on to Ember because of the people behind it. Like I, they come from the Ruby land and all that, and I respect you. we've had him on the show multiple times.

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 it. I could tell, right, there's so much work to do before this is awesome. And then I kind of looked at Angular and Angular was more productive immediately. And so I had like a six month love affair with Angular.

And then it kind of, you know, got faded on a little bit, but now with Ember 2.0 and it seems like Ember is finally here. Is that safe to say? Like Ember is now arrived and it wasn't really like, you guys probably had a lot of shoring up to do around it back then. Ember's been slowly arriving for a while now, right?

It's like this, it's like this massive ship that's coming into the harbor being pulled along by a tiny tugboat or something. I don't know. That might be a bad analogy. But yeah, it does.

I, 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, we're, you know, this is the direction that we want to go in. Ember 1.0, I think that they, 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 that the use cases have really driven the direction of Ember.

I think will Chatbots of the day, 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, you know, 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 rebuild and redesign Dockyard.com around Ember and Phoenix.

It was a little bit of a bumpy road, mostly because we were trying 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 think it was production ready released. So FastBoot was or is Ember's solution for server-side rendering of your Ember application for the purposes of SEO.

Right. 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, 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 it, 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 then it would be there and then Ember would launch in your browser and I think the process they call it is hydrate the DOM. And so it would just kind of realize that this is already an Ember generated application, Ember just 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 FastBoot at the time had some really ugly memory leaks in it. And so we, like most memory leaks, they did not come up until after our production. Right.

So Dockyard.com. Always benchmark your applications, I guess, or stress test them. Right. But we're so excited to get it out.

So we had to pull back, and what we actually, I think actually Dockyard, someone may say, hey, we had one out before, but I'm pretty sure that Dockyard.com was the first production FastBoot 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 up, you know, them up to 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. Like, even though we're still using Ember, that was the complaint that people always had, like, oh, Ember's so fat, Ember's slow to load. Right. If you go to Dockyard.com, I think on average it loads up in like 0.75 seconds, which is pretty quick for a client-side application.

We were able to shrink down our asset size, I believe, close to 200k, somewhere around there, which is pretty reasonable. And we, like, our blog actually sits in the database. And so when you hit the blog, this is being served up by Phoenix. And it's, I believe, the whole page or just the data?

The whole page. All the data. So if you were to, if you look at your, like, 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, like, dumb API that's just being served up data, and then Ember is our client-side. And we don't, we haven't heard any drawbacks from doing it this way.

We haven't heard of having 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. But it's a very fast website. Like, switching between pages is very fast. And that's what I want out of an application.

And so that's why I say that we feel that this is the way to build it because speed and response time is, I think, becoming a very, very important concern for usability and the 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 hash, you know, hashtag in the URL or anything. You've got your URLs are clean.

Does that still, Ember's 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 AutoLocation, actually. And in Ember, AutoLocation will detect whether or not you have the history API in your, whether or not that's available to your browser. And if it does, it'll give us this nice, clean, you know, URLs. If it doesn't, it will fall back to the hashtag, go to the hash version.

Right. I think, like, IE 10 below, I think IE 9, IE 8 stuff, they may fall back. But most evergreen browsers now, I believe, are all evergreen browsers are actually history API. So what is AutoLocation?

Is that a library? Is that part of Ember proper? It's part of Ember. So if you were to go to, if you were to generate a new Ember application with Ember CLI, I think it's in the config environment file.

There may be something about location and then it says auto. I think it's, I'm talking off the top of my head. I think it may be there, but that's where Ember's router will decide what type of URLs it's going to generate through its links. Yeah, I just found the page linked up in the show notes.

It says Ember AutoLocation will 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 FastBoot or you're using a... We're using regular FastBoot, but we're not allowing public access to it. Gotcha. So Nginx is only serving up our cached generated templates right now.

You kind of crawl 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 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.

Yeah. Good heavens. That'll be definitely interesting. Gosh, what else about this?

So just perusing, I thought this definitely loads fast. I mean, initial load is slower and then, but it's still pretty fast. And then obviously your page navigation is super fast. And I know what you're using it kind of as like, we're, we're investing in these technologies.

We're going to use these technologies. Does it, is it possibly over-engineered for what you guys are trying to accomplish with your website? It's over-engineered content site for sure. I don't, 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. 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 are still use cases and there's still what are you trying to accomplish? And let's build a 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 and you're kind of pushing the leading 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.

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, as we do in the United States.

Or if I'm not sure where you are, but the US, I think we That's a big market if you can get it. Cool. 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 that 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'd actually have to do the opposite. I have to stop playing with stuff because I got, I got, I got like developer ADD and I get on to too much stuff. I mean, that is probably part of the reason why I pushed my company in the direction I have rather than taking the safe bet and keep doing Rails.

Okay. I mean, if there's something that I want to do more stuff with distributed code, 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 Vorhees. Any other cool open source, you know, GitHub projects that you or Dockyard's up to that you want to give a shout out to? I have like a 25% completed Elixir. They're called applications in Elixir, not libraries.

I think that that's a, that's a, uh, Erlang term, which still feels a little weird to me, but I have one that I'm, it's kind of like a fixture library for, um, well, for Phoenix, Phoenix applications, Elixir applications. Um, it's going to have a very simple DSL for declaring fixtures. Do you have a name for it? I just have to call it fixtures right now.

Yeah, it's not very creative. All right, cool. Well, um, distracted searching for it on your GitHub. Is it still, you're working on it.

It'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, I only brace robots 70% of it. And then I, I moved on to something else. Yeah. Then you find a new thing.

Uh, well, Brian, thanks so much for joining us. I really enjoyed, uh, putting your brain on all these things. Um, how can people reach you out there on the internets? Um, probably don't want to follow me on Twitter, but if you want to check out at Dockyard on Twitter, we put all of our stuff on there.

We actually just finished. So we hosted, we hosted a conference with EmberConf in June. We had about 200 people there. We were on an island.

So we talked about that experience. We, uh, uh, mentioned our blog posts through our Twitter account. Uh, that's probably 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 wanna 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, NeoJS 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 king. Give us a shout there with your show ideas, entering projects that you have or that you've created, or just to say hi. We'd love hearing from you. I wanna announce that we're going to become a Crystal development shop.

Oh, breaking news. Yeah, it's 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. See ya. Oh, goodbye.