archive-fm.com » FM » S » SIMPLECAST.FM

Total: 24

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • Frontside the Podcast
    and proposes to the entire internet 16 March 2015 20 Best of EmberConf 2015 part 1 Charles and Brandon share their weekend foodie experiences then discuss attending EmberConf 2015 the standout talks and what they learned 28 February 2015 19 Origin Stories with Tom Dale and Alex Matchneer This week Charles Brandon and Stanley were joined by Tom Dale and Alex Matchneer They took a trip in the way back machine to discuss how they got started in programming and web development 4 February 2015 Back End Devs and Bridging the Stack with Toran Billups Toran Billups joins us for this week s Frontside podcast We had a great conversation about test driven development code rot the challenges of bringing back end programmers into front end testing why Toran loves pair programming and more 27 January 2015 Hiring Junior Developers The Ukelele Method This week Charles shares an experience he had at a group Ukulele lesson with his son and applies the lessons he learned there towards hiring and creating roles to utilize junior level talent in software development 23 December 2014 Ember 2 0 and the Indie Web with Yehuda Katz and Tom Dale Yehuda Katz and Tom Dale join us to talk about the road to Ember 2 0 and Fast Boot They share insight about why they stick to a 6 week release cycle and why they think JS frameworks might be the future of all web apps especially content sites We also chat about what indie open source means and exactly how much design goes into the Ember project and community 16 December 2014 DOMStep with Jamison Dance Jamison Dance joins Brandon and Stanley to talk about how to make music with your browser hosting JS Jabber and the direction of the JavaScript community 7 December

    Original URL path: https://frontsidethepodcast.simplecast.fm/ (2015-04-03)
    Open archived version from archive

  • 22: Deploy to the Future with Luke Melia | Frontside the Podcast
    startups and see if we don t learn something along the way 30 March 2015 22 Deploy to the Future with Luke Melia 1x Charles Brandon and Stanley are joined by Luke Melia to discuss being early adopters of Ember Ember CLI Deploy and growing the Ember community Show links Luke Melia Luke on Twitter Yapp Ember CLI Deploy RailsConf 2012 Lightning Fast Deployment of Your Rails backed JavaScript app

    Original URL path: https://frontsidethepodcast.simplecast.fm/22 (2015-04-03)
    Open archived version from archive

  • 21: Best of EmberConf 2015 (part 2) | Frontside the Podcast
    the way 19 March 2015 21 Best of EmberConf 2015 part 2 1x Charles Brandon and Stanley wrap up part two of their discussion about their favorite talks and technologies from EmberConf 2015 Stanley sings a Staind song and proposes to the entire internet Show Links Ember CLI Deploy Aaron Patterson Tenderlove Orbit js Jamie White Growing Ember One Tomster At A Time Ember Community Guidelines Brittany Storoz Building Custom

    Original URL path: https://frontsidethepodcast.simplecast.fm/21 (2015-04-03)
    Open archived version from archive

  • 20: Best of EmberConf 2015 (part 1) | Frontside the Podcast
    Austin technology startups and see if we don t learn something along the way 16 March 2015 20 Best of EmberConf 2015 part 1 1x Charles and Brandon share their foodie weekend experiences and discuss EmberConf 2015 highlights and what they learned Show Links Black s BBQ Smitty s Market Lockhart Charleston Wine Food EmberConf 2015 Godfrey Chan Hijacking Hacker News HTMLBars Lauren Tan Ambitious UX for Ambitious Apps Toran

    Original URL path: https://frontsidethepodcast.simplecast.fm/20 (2015-04-03)
    Open archived version from archive

  • 19: Origin Stories with Tom Dale and Alex Matchneer | Frontside the Podcast
    t learn something along the way 28 February 2015 19 Origin Stories with Tom Dale and Alex Matchneer 1x This week Charles Brandon and Stanley were joined by Tom Dale and Alex Matchneer They took a trip in the way back machine to discuss how they got started in programming and web development Show Links Tom Dale Follow Tom on Twitter Alex Matchneer Follow Alex on Twitter Icon Factory Copland

    Original URL path: https://frontsidethepodcast.simplecast.fm/19 (2015-04-03)
    Open archived version from archive

  • Back-End Devs and Bridging the Stack with Toran Billups | Frontside the Podcast
    something along the way 4 February 2015 Back End Devs and Bridging the Stack with Toran Billups 1x Toran Billups joins us for this week s Frontside podcast We had a great conversation about test driven development code rot the challenges of bringing back end programmers into front end testing why Toran loves pair programming and more Show Links Toran Billups Follow Toran on Twittter Ember Conf Alt NET Mike

    Original URL path: https://frontsidethepodcast.simplecast.fm/18 (2015-04-03)
    Open archived version from archive

  • Hiring Junior Developers: The Ukelele Method | Frontside the Podcast
    Austin technology startups and see if we don t learn something along the way 27 January 2015 Hiring Junior Developers The Ukelele Method 1x This week Charles shares an experience he had at a group Ukulele lesson with his son and applies the lessons he learned there towards hiring and creating roles to utilize junior level talent in software development Show Links Brandon Hays Open Allocation Ruby On Rails Podcast

    Original URL path: https://frontsidethepodcast.simplecast.fm/17 (2015-04-03)
    Open archived version from archive

  • Ember 2.0 and the Indie Web with Yehuda Katz and Tom Dale | Frontside the Podcast
    expressive the templating and in fact the entire application architecture is and because we all agree as a community that this is how we architect our apps it unlocks a lot more stuff And I think there ll be more things like server side rendering in the future that we all benefit from by sharing this very declarative application structure and very declarative templating language YEHUDA Yeah I mean honestly under the hood the fact a lot of the innovations of the templating engine are not things that any user will ever see directly because they re just implementation And if we wanted to go around pimping things like streams or the way that the diffing algorithm works internally and the way we clone fragments and all this stuff we could probably spend a lot of time pimping it and maybe that would even make a lot of people some people happy But I think you ll see over the next year or so these things will all lead towards better features or to more features that will be nice and that s how I think we d like to roll TOM I think Web components integration is a big one YEHUDA Ah yeah that s a good point TOM I think HTMLBars makes it very easy And so in terms of actual improvements coming on top of HTMLBars the component syntax instead of being curly curly to indicate that you want a component you ll be able to use just regular angle brackets so that ll be nice And another thing that we re really keen to get rid of is You know how today when you re building an Ember component if you want to customize the element associated with that component you have to say like tag name class name bindings You guys know what I m talking about BRANDON Mm hmm TOM So that s kind of annoying because all of those special properties on the component class that you used to customize the element are all duplicating features that already exist in the templating language So it s just kind of this weird bifurcation of the programming model where if you want to customize the element for this top level do it in JavaScript Everything else do it in the template So HTMLBars will allow us to allow you to customize your component element purely in the template and you won t have to basically there are far more cases now where you ll be able to get away with a component that s just a template file and you ll reduce the number of JavaScript classes in your app YEHUDA Yeah I think from a high level the biggest the high level of the internal technical improvements are largely that it allows for contextual work So the old templating engine wouldn t necessarily know that you re inside of an attrf when you have curlies so we would have to spit out a bunch of extra stuff and maybe make you use extra helpers It wouldn t necessarily know that you re in image FRC or a video tag or a component It wouldn t be able to tell if you were using a polymer component that implements the bind protocol right But the new templating engine basically lets us see exactly what s happening at every curly and that just has a large number of positive effects BRANDON So you said something else that I felt like was a good segue into the next part of the discussion that this basically allows you to do server side rendering which you guys are really like in the thick of it right now But for me a lot of the talk I ve seen a about server side rendering comes across as a little inside baseball There s this sort of discussion between people who are really into React because they re suddenly doing a lot of stuff with server side rendering and they re seeing some benefits out of it And you see this stuff kind of pop up in the JavaScript community but I m curious to know if you guys can explain a little bit about the benefit of server side rendering that this is a major new feature coming to Ember now YEHUDA I ll let Tom maybe give the full pitch but I think one thing that I feel somewhat strongly about is that for most people if you don t have a system that actually gives you something that works pretty well out of the box in other words it doesn t ask you to do a lot of the work yourself the idea of isomorphic server side rendering where you run your same app on the client and the server I don t think that that ends up being worth it And if you look at a lot of apps that use Ember today a lot of them have spent relatively little time building non isomorphic solutions for specifically SEO that have been very very cheap in terms of time and very very effective But I think there s the I want to not have to write that even that little bit and I think that that you get a lot of benefits out of if you just have your framework do it In other words if it s not just like your framework does 20 and you do 80 If it s your framework does 95 and you do maybe a little bit or you have some constraints I think that is worth something And I think the rehydration of fast boot is worth something although that has even more issues and even a larger percentage that most people have to do on their own Basically I think the TLDR for me is that I ve always saw server side rendering as indeed somewhat inside baseball because for most people historically and I think this is even true largely about React the solution that you re offered is the framework will do a little bit for you and you have to go figure out a lot of the details about how to make this work for real And I think most people just don t have the time to figure all those details out TOM So it s been kind of interesting to watch this play out over the last year or two because I think there s been a big split between the JavaScript application community and old school people that create content for the Web who are really keen on this idea of progressive enhancement And so there s kind been this split And for me for a long time I personally didn t really care about this case because in my mind JavaScript apps were really good for what I ll call workspace apps which is most of them are behind a login You log in You have these very rich interactions You re editing something You know I worked on the iCloud apps It s a feature not a bug that Google can t index your calendar and your email right So to me that was the use case for JavaScript apps But that was until I saw content sites Like I remember the first time thinking Wow maybe JavaScript apps are actually the future of all Web applications was when I saw Bustle actually When I saw Bustle it was just a content site It was just news articles And if you would ve asked me I would have said you should probably use Rails or some other server rendered framework for this But then I saw it and it felt just like a website I couldn t actually tell the difference other than how damn fast it was And I kind of had to step back and question all of my opinions about how people should be building these kinds of applications And especially for content sites I think that the server rendering is really important right because historically your user has had to download all of this JavaScript and all that JavaScript had to be downloaded and evaluated and run before they saw anything So having the ability to bootstrap that process on the server and have the first bits that the user starts downloading not be the JavaScript payload but be HTML and CSS so that the first thing that they see is useful I think that s really going to change how people build applications because you get the benefits of server rendering while still retaining the kind of interactions that you can build with something like Ember that you just can t do with Rails YEHUDA But again I think people trying to do this on their own and taking maybe a half solution and then trying to figure out how to make this work reliably ends up producing things that are pretty buggy and feel pretty bad on first boot or they end up requiring tremendous amounts of engineering resources And it s possible that like huge companies can make this work But I mostly think about startups and startups simply do not have the engineering resources to take on the server side rendering task on their own so this is why I think we care about it for Ember because as Tom said before Ember is already pushing you down a pretty conventional path and we think our hope is that by having people do that conventional path and us taking charge of server side rendering will have something that works mostly out of the box for a lot of users Again assuming they follow some additional constraints about what you re allowed to do on the server TOM And I think we should be clear here because there s as always happens there s ambiguity in the terminology So first is the term isomorphic app which I don t really love that term but I guess we better get used to it Yehuda YEHUDA Yeah TOM But there s really a spectrum On the one side of the spectrum you have something like Airbnb has a library for Backbone called Rendr with no e well one e but not the second e And that kind of lets you wire up some of the server side rendering But again it s very very manual And the whole purpose of this is just to make sure that the first thing that you deliver to the browser is HTML and not JavaScript so that the user even if they don t have JavaScript enabled or they re on a slow connection or whatever they get something useful But then on the other side you have things like Meteor or Asana where the whole idea is and to me I ll be honest with you It strikes me as extremely silly but the idea is that you re writing both your server and your client in the same code base and then you re deploying them both You describe it and it sounds like this magic bullet but it also just seems really silly to me YEHUDA Well I think the fact that even the first releases of Meteor had if Meteor isClient and if Meteor isServer and even the first demos had large blocks of content TOM Yeah Conditionals Yeah YEHUDA Basically means that people hadn t really figured it out exactly right yet TOM Yeah the point is that even if you have a client side app your server still has a lot of responsibilities especially around data access to the database authorization authentication and so on And putting that in the code base with your UI and your drag and drop code just does not make any sense to me So I want to be clear to everyone listening that that is not what we re going for The idea is not that you re writing your json API server in Ember The point is that you re writing the same old app In fact we hope that you don t have to make any changes to your app And you can deploy it and it will do a render using the same code It s basically like your app running in a browser on the server and then we ll have some way of YEHUDA Except not actually a browser TOM it s actually a transferring state YEHUDA Except importantly it s much much cheaper than being an actual browser We re not using phantom JS or a zombie or anything TOM Right Conceptually a browser but we don t want to pay the cost Phantom JS is a source of great pain for many people ourselves included so we want a pure JavaScript environment But conceptually it s a browser YEHUDA I think the reason I hopped in there is I just want to be clear that the goal of conceptually a browser is actually not to be a browser but to make Ember itself internally abstract enough so that the most expensive parts of being a browser can be replicated in a cheaper way on the server Obviously the most important part of that is the DOM And that s the part that React worked out for server side rendering is use the virtual DOM on the server and not a real DOM right And that means you don t need real phantom JS and the full scope of DOM But there s also other stuff like how your routing works and how the model hook runs and how it makes requests how it makes XHRs to get the data in the first place Right There are a lot of details if you think about what it takes to boot up an app in the first place For us the goal is to go through that whole process of booting up an app all the way through but not including the did insert element hooks in your DOM and make sure that all that stuff doesn t require it has really constrained and clear abstractions right So rendering has a render abstraction and routing has a location abstraction and the DOM has the HTML bars little dom lower case dom abstraction right So instead of saying we re running it inside of something that pretends to be a browser we re saying Ember doesn t actually care whether it s in a browser or not but it has very very clear abstractions for what it means to be a browser BRANDON Okay so is there It sounds like it could be a little like is this a little ways off It sounds like there are a lot of benefits Like if you see the hand rolled stuff that Discourse has done clearly this is something that Bustle cares enough about to sponsor this is probably a little ways off for Ember developers Is there anything that you want people doing Ember to know right now about server side rendering in terms of how it s going to affect them or some of the technical stuff that you re learning through this or anything like that TOM I think we ve been thinking about this particular problem for a very long time And in fact we ve intentionally designed the architecture of Ember specifically to handle this case even from the beginning even like three years ago We knew that this is something that we wanted or at least we didn t want to paint ourselves into a corner around So I think there are two aspects of this and one of them I think is pretty well bounded and pretty straightforward The other one is definitely going to require a little bit more research The first step is simply getting rendering happening on the server So because we designed Ember for this case we were actually able to get Ember as a framework booting up in node in about a day s worth of work So a couple things have crept in There were areas where we had been a little bit sloppy and introduced dependencies on things like document body jQuery things like that So it was about a day to kind of encapsulate those make sure that they weren t hard requirements for booting the framework and that was about a day s worth of work And then by the end of the week we ve only been working on this for about a week now at the end of the week we actually had an app booting in node and handling route requests So in terms of progress it s been really great But I guess all that we re saying is that in a week we were able to capitalize on the last three years of work we ve been doing That s not as impressive as it sounds YEHUDA It was nice that there were relatively few regressions right TOM Yeah YEHUDA That the list of things where people were accidentally doing things that assumed the browser was actually relatively small TOM Yeah And the way that we did that is basically introducing an abstraction that provides your environment to you so a node that s different than in a browser So that s the first part is to get the app booting and the second part is to get it rendering I think what s really cool is that even though HTMLBars of course is a DOM based rendering engine or despite that we still use an abstraction around DOM access What we re going to be able to do when we start again in earnest tomorrow on Monday is basically replace that DOM helper that we used to create DOM in the browser with something that we ll be able to build up strings so that you can build up your HTML on the server and serve that to the client That s step one rendering I think we ll be able to make quite quick progress on that I would guess probably about I don t know if I should give timelines here I think we re ballparking around a month before we can at least beta it the server rendering BRANDON That s a little faster timeline than I had assumed TOM That s purely rendering I want to make clear that that is purely for things like SEO for Web crawlers for curl things like that Then the next phase after that and this is where it gets into the tricky bit is being able to YEHUDA Rehydration TOM is rehydration what people call it What we call fast boot And with fast boot the idea is that whatever state that we use to build up your application on the server we also transfer that state not just the HTML not just the output but the state that we use to build that output is somehow seamlessly transferred from the server to the client And the client basically just takes the HTML that we ve given it and reconnects all these bindings and goes from there so it s totally seamless to the user YEHUDA And I think there s some complexity there For example there may be some part of your page that you can t actually render on the server because it says like Hello authenticated user with the user s name So thinking about ways to make sure that you can mark those as needing to be rendered on the client without causing jank There s a bunch of stuff like that where at first glance it seems not too bad but I guess the high level if there s a determinism issue right So the goal is to make sure that roughly what you did on the server is the same thing that you do on the client because if it s too far off then you end up having to throw no matter how smart our algorithm is we re going to end up having to throw away everything and replace it again The idea is how to structure your app how to structure the way that you set up your app in Ember CLI so that you tend to be putting out output that s deterministic on both sides And like Tom said I think state is maybe overbroad It s mostly modeled batter right Making sure that the model batter that you got on the server is equivalent and transferred together with the HTML payload so that the model hooks that you have in your client will not have to go make another XHR They ll just have the data that the server already collected and then hopefully rerender an equivalent DOM on the clients with relatively low TOM There are just a lot of tricky cases like imagine you have a bound helper that shows relative dates like 30 seconds ago So you have a clock on the server and then you have a clock on the client How do you reconcile those two YEHUDA Yeah so the good news there the good news with all that without getting too much into the weeds is that the HTMLBars engine is already broken up between rendering the parts of your DOM that are static that are like the hello the text hello inside of an H1 and updating the static parts with dynamic content And today that s purely a performance optimization and so that we could use the same document fragment over and over again after cloning but that will also allow us to use server rendered content where instead of expecting to have an empty text node that is to be filling in with dynamic content we ll have a filled in text node And we see in that case Tom that the time that is in there already is not the correct time It s not the equivalent time and so we ll update it So that s sort of like the React diffing strategy I m less worried about like there s a single text node with the wrong content because I know we can deal with that And I m a lot although if it s too much changes it will look very bad It will look very janky I m more worried about like this entire conditional change So you re looking at something and then like your sidebar swaps out for a different sidebar which I think would be a pretty unacceptable UI CHARLES Obviously there are a lot of different server side environments that people use What requirements of the server is there going to be if I m using a Rails app or something in Python or Java or whatnot How am I going to interface to this TOM Well you definitely need a JavaScript runtime right because your Ember app is written in JavaScript Unless you re planning on pouring it into Ruby or whatever we re definitely going to require JavaScript runtime And I think we re starting with just supporting node But what I would like to see and maybe you guys can write this is a Rails gem that you can install that will install dependencies in everything and basically get set up in a production environment YEHUDA I think one thing people often forget is you can definitely you could you have a node app running People try to embed JavaScript They try to use like The Ruby Racer and embedding JavaScript is quite a disaster BRANDON Laughter I m sorry I don t know if you know Charles wrote The Ruby Racer and it is a disaster STANLEY It s cool It s a disaster YEHUDA So let me be clear It s a great idea I use it a lot but it just fundamentally doesn t now work Right It fundamentally cannot you cannot embed two VGCs in the same process BRANDON Right YEHUDA Okay BRANDON This is the greatest moment in the history of our podcast I just want to say that CHARLES No I know There s no way to collect YEHUDA Yes exactly CHARLES for example YEHUDA I was about to use cycles as an example CHARLES The APIs just don t exist YEHUDA Yeah so basically cycles so this is why The reason why I feel strongly about this is that we use Rust for Skylight which is our product And we need to embed something and I would never in a million years embed something with a garbage collector And I think The Ruby Racer was a pretty good I think for constrained cases it works fine if you know what you re doing but people basically tried to use it as Oh I m just going to write part of my program in JavaScript And by the way both languages have closures so good luck basically The Ruby Racer is cool but I would not I don t think that that s the correct strategy for having long running JavaScript programs like Ember like complicated stuff like Ember I think a better thing for people to do would be to figure out a simple IPC protocol so that they could run their Ember app and then have a simple way of talking over a socket or something with the node app so booting up your Rails app will also boot up the node app And if necessary and you re serving through your Rails app you could communicate TOM I think to be clear the Ember app even when running on the server still talks to the database server using json right So it s the exact same data marshalling flow It s just presumably it ll be a lot faster because probably your API server and your application server are in the same data YEHUDA Well at a minimum it ll be a lot more consistent right TOM Yes YEHUDA I think when people when Twitter complained about somebody from some country connecting and getting a really slow connection the issue there was that they were downloading the app shell and then who knows how long it took to download the json payload right But if the json payload is coming from the same data center then it s by definition going to be downed within some range reasonable range BRANDON Okay Awesome I d like to shift gears and spend a couple minutes talking about something that most of the questions that I had originally for this were actually answered in your talk But I d like to go over it just a little bit You alluded earlier to the way that you re running Ember as an ideal sort of your ideals discovering your ideals about open source projects and the Indie Web And I think it s a really important topic and I want to ask a little bit about that because I don t think a lot of people understand this I think especially I see in the JavaScript community a lot more people establishing open source projects that are corporate run and that being considered a benefit rather than a drawback And I ve seen you push back on that a little bit and I wanted to ask you Yehuda about what your definition of the Indie Web is and why you specifically run the Ember project the way that you guy run it YEHUDA Sure I think there are basically two parts of what it means to be Indie and the second one sort of derives out of the first one but I think it s you wouldn t necessarily arrive at it yourself so I ll make it explicit The first one is that you have a diversified core team What I mean by that is essentially diverse in all the ways you could possibly think of and things that I learned from other projects are like functionally diverse So make sure that if there s a person on your team if there s a person around somewhere running your events or doing documentation or doing evangelism or running user groups make sure that if there s a person who is very skilled at doing that that they are the top person on your team in charge of that The counter the alternative that I ve seen a lot in the open source community is that the person running events essentially reports to the core team right There s a person who is maybe a professional event runner and they are not in charge of events They re in charge of coming up with ideas for events that they run by the core team and the core team decides yes or no The problem is the core team has no skills in doing that so this person ends up spending huge amounts of time being frustrated trying to explain to the core team something or other right That would be the equivalent of somebody on the core team writing some area of code having to come to the rest to the core team and talking about really tiny nitty gritty implementation details Of course unlike code where I think people have an intuitive sense that you re deep in the weeds of some performance thing and I don t really understand that In a lot of areas that are not code code people have a very high sense of their own understanding right The core teams I ve seen a lot of core teams that people come and they say well I happen to know a lot about how people want to read docs in this country and so I m going to help with the translation effort All of a sudden the core team is an expert on like Indian documentation And they have all these opinions that are totally unwarranted Step one is have a functionally diverse group of people and have people that are not necessarily hardcore coders but are talented and professionals in their area Have them do that work at the top level And I spent a little time on this just now because I feel strongly that this is an area that people miss and it s just an area that code people are too high on their own supply They re too impressed with their own skills They cause a lot of pain for the people who are good at areas that are not hard core code so that s one Two is be diverse in terms of the set of people that own decision making in your project so this is what you were talking about with the company run open source and this is something companies can do I ve seen for example I worked with the Rust Project and the Rust Project originally started at Mozilla But they ve been spending tremendous amounts of effort to try to increase the set of people who are on the core team of Rust that are not working at Mozilla And this is something that maybe takes a lot of effort once you have an established project at a company There s all the internal company politics you have to deal with But the reality is that if you have a project that s at one company you re kind of at the whims and the mercies of that one company s how they do resourcing whether they think it s important what their actual goals are Maybe the thing that they built the project for doesn t necessarily match what the community is doing right So become diverse in the companies that own it I think projects like Rails Postgres Ember increasingly Rust are good examples of this And of course I mean the regular meaning of the word diverse here just because if you become more diverse in all areas you actually find yourself being more function diverse just because of who ends up being in what areas You end up finding yourself having a lot better insight You end up sitting in a room and when there are people of diverse backgrounds the kinds of questions that people ask And I can only say this This is the thing that I ve noticed personally It s not a thing that I can empirically measure I ve just noticed that the kinds of questions that people ask when you re diverse in all kinds of ways ends up being they end up being stronger better and they end up pushing back on the kinds of decisions that you can make as a monoculture with group think right The harder it is to have group think the harder it is for everyone to sit around and say You know what we re going to do We re going to rewrite everything right That kind of thing is hard to do when you have a lot of people with a lot of different backgrounds with a lot of different interests So that s I think the higher order bit of what in the open source means is be very diversified in a lot of different ways But there s a specific thing that I think comes out of it that is very important which is to do the work that you re doing incrementally Again the reason I think that this is a derive is that if you have a lot of people with a lot of different interests with a lot of different projects I think it becomes very difficult for you to do full on rewrites because everybody has interests and maybe a few people are excited about doing a rewrite but everyone else says Oh my God What about my app Then you have the docs guy saying Oh my God Now we have to maintain two sets of docs And you have the evangelism guy hearing all the pushback from the community about the rewrite So it becomes very difficult for you to have this situation where you re not doing things incrementally But I think in my talk I spend some time on what it means to do things incrementally and what the benefits are and how to adopt the six week release cycle and all that I talked about that in more detail because even though I think it s a natural consequence of being diversified it s also something that you have to think about if you want to do it well BRANDON Yeah It seems to me that that would require like it s kind of a chicken and egg deal but to me it seems like there was a lot of discipline in switching to a six week release cycle and that s important It seems for us at least as consumers of Ember as an open source framework that s benefited us greatly We find the framework much much easier to keep up with on the six week release cycles than pretty much most other open source projects we ve worked with YEHUDA Which is kind of like a paradox right because you expect that six week release cycle means you can never keep up with it because it s always changing But in fact six week release cycle means you don t have time to ever change that much BRANDON Well and even for apps that go dormant for a while we find that okay we ll bring it up to one Bring it up to the next one The upgrade path becomes extremely obvious YEHUDA Yep exactly and there s deprecation warnings and there s I think people should watch my talk on this specific area because it took me 15 minutes or something to lay out the whole thing But I think the basic idea

    Original URL path: https://frontsidethepodcast.simplecast.fm/16 (2015-04-03)
    Open archived version from archive