Bestand wählen
Merken

The Chirpolith: Successfully Migrating A Mess App to Ember

Zitierlink des Filmsegments
Embed Code

Automatisierte Medienanalyse

Beta
Erkannte Entitäten
Sprachtranskript
and that this that this happened
to happen to do thank you so
yeah the my name's Alex Rosenberg and I'm really talking about the choropleth and how we spend you know the last year migrating a messy application to member so I work at a company called I or
health and now were founded by doctors in our mission is to restore in health care so we do that by running primary care practices around the country and where we serve about 15 thousand patients right now and you have you bend your doctor recently you probably noticed them in the corner taken computer and if you looked over the shoulder you may have seen sort of an ugly applications what a gray boxes and complicated interface sort understand and that's because those applications are typically been built for billing systems for insurance reasons not for patient care so every hour CEO would use all others systems in the past and 1 of the 1st decisions we made as a company was we were going to build our own because he hated pretty much everything he had used in the past so we call a system which and you know it's really designed to do everything that we need to to help the practices runs everything from scheduling to documenting a visit to ordering labs to now refilling prescriptions land from day 1 it's been adjusted to every application we wanted to be friendly and easy to use and really get underway between the doctor the patient but the other day 1 was a long time ago so we started building it back in 2011 and at the time the savior for jobs with respect so we started as a background application and back was great but it's much lower level than the to like embers today at a much lower level library and before long we realized we weren't only building on application we were building a custom ad hoc framework on top of that so you know we looked around the community and there's something called back marionette to is emerging so we start to take pieces or application extract them into a separate application built using back a minor and that worked well but we are we kept looking around and we saw number 10 no we I say red amber so we did the same thing we took other pieces of application extracted out and at no you can imagine right Rabin you get a pretty messy system a lot of different technologies lots of applications but no we're on even done yet because we also looked around and saw react and now we thought this time we would make the same mistake we do something different so reactive you later we thought can we just users of you layer backbone applications and we did that and that work pretty well but you know we really sir
page ourselves into a corner now at this point we had a pretty complicated now Budget technology bunch of application that we as engineers did really wanna work on and to the product came clustering to them because everything was expensive and hard to make changes to so you know it took us about 5 years to create this mess and when you talk about is how we spend basically last year plus being ourselves out of this mess so know what we
desire was we work and I now make the same mistakes we made in the past probably make our own special new mistakes but here we're going to try and learn from the past so we thought about the things we done wrong before FIL stand you know the 1st thing is you know each time we try to dig ourselves out we really know where we're headed so we knew the small little thing but if those wildly successful we did know wild success would look like so some use ii wild success would look like a nice clean them around and something similar where you create if we greenfield world and Brownfield world where now the 2nd thing we did is each time we extracted chunk of functionality we did is a big bang release right so you saw nothing nothing nothing there we dropped this big change on them so we work and do that again we're a working really small incremental changes you know the last thing we did the changes made our world more more complex so we work do that right we're going to reduce ANOVA Technologies we had to reduce the number of applications and the last thing is we can never maintain armament on every time we started off a star like gangbusters but then we know we lost no we lost interest lost motivation and know this so we can always some techniques to keep motivation for process so because we worked with all these technologies in the past you know we realize that have squinted hard enough see you ignored all the details with the application they all pretty much do the same thing right so they take you are a land they do some pattern matching and the world figure out what to do with that they call some API salute data and then they build interactive down you know with that data on and you know that was true of all of and we also realize that from only done experiments with no using react as a view layer inside the backbone of the committee's technologies together so we thought What if we did the same thing as our experiment we flipped around which would put Amber in charge let it take over the routing layer but made use of all our existing backbone code and then slowly over time we could replace the backbone code with number could do we end up with a nice number so that's no project you talk about you we did so let's get started so
the 1st thing we need to do if we're aiming toward having a nice clean at the end of the day was we needed to it met we you know how to do that so we brought in Mike North from front and masters to do some training and then it was really great now he came in for a couple days it really gave us a great foundation of however work the flossy behind member had a think of routs components models rate ball that town but something else he gave us was lost as the voice of authority so later when the time came to start building our application and we would begin to get into the religious debates that all teams get into we can back off and say let's just do it the way we learned in training and cut those debates of the that so we want to build a
nice thing rap know we did away all the guys would do it right Amber no which Seromba but now we weren't really building a green feel that this is a brownfield world so we had a little bit of work to integrate it with our existing build scripts existing deployments crops and you know basically we treated all of our legacy background code as a third-party vendor code so we could just call into it by learning about life so now we had a nice and Beate did absolutely nothing the time came to make its are doing something
so we know we start at the top layer
with the router and you know 1 of the things that are doctors do a lot in the offices their documenting the visit right so the writing notes and reading the old nodes to remind them what happened previous visits and you know we looked at our old backbone routing tables and you know when we start creating the amber routs you know they they did the same things but the fact Amber pushed us into having these nice nested routs all a and I was really excited right so when we start having a note view rel and no-show wrote it could really focus on just the note right in have to load the patient and everything else for the other parts of the we had an ancestor out to take care of all that and the Note Châu routed really just focus on them so we went on and started building that rat out and you know when you typically think of building a rout the model hook right you you're probably used to thinking of calling into amber data to low your model but there's nothing says it has to be amber data so we're able to call into our old backbone model and load the data that way which was great and if you look really carefully here you minus right this is not just loading the no it's getter fetch with his all backbone world we didn't have something like amber data that would do some intelligent caching of what's in the browser what sort of in letter and not to we built around caching mechanism and you know it's kind of a joke in computer science occassions where the hard problems but it really is 1 of our problems and we really didn't wanna be in the business of maintaining on caching library so again we're excited for the day where this would go away and we could slip in number data land where this would take care we would take care of this for us so we had a rout we went on to build component so we did pretty much a similar pattern where we would call into our old backbone view that would load the view for us passing and you know the model which remember is the backbone model so it all worked fine and the only trick here was he had to get that back on view to render itself in the pay is a part of the page that Emirates set aside for the components so turned out that was not hard know in the component we could as a component for the DoD element and the number set aside for us this passage the backbone view you would render itself so last thing we did is just a little bit a cleanup when Amber tears down the component we just tell the backbone view to clean up after itself unbind events where also might need to do so will this
work can you know the answers for the most
part yes know inside the red box we have a component we just go right so it is loading data from the API and displaying on the page so that was great but if you look at the top we can see a link to notes that the has back to the index page of all modes user look carefully at the link here right starting with the hatch and again that's because back we started this application no hash Ahlfors how he did from navigation now of course that's not going to work in a modern number where we use really worlds so you know at 1st new we also going too fast this is now we're going after going to all world could find all the links and start rewriting them and that seemed like a huge pain in exactly we want to avoid which is not going to that back to but you know them we realized Amber was actually give us the tools that we didn't have to do that so we wrote know a little bit of code stuck in instance initializer and what it does is it uses embers hash location API to ask it to notify us any time the hashed your all changes whenever does we just rip off that leading harsh and send the rest the all into the emperor where you know if it's your all that we've already rewritten and we have a out for Everything's our great in the amber routable routed to the appropriate rout and if it doesn't we just stuck in new wild-card wrote the bomber routing table that would never get us out of our new emperor back to the old legacy and now once we did that it actually worked you know we could not display the data but we had length now crossed knowing you also makes worked as well know but there's a problem in navigating between 2 apps was really slow you know every time you leave an app you you left the umbra up load the backbone up you click the link will the umbra upright loading a new app takes time so now likely we had a good feature totalling system so we were able to keep no migrating these routs and releasing them without turning on for users so without inflicting that pain on our users and took in about 6 weeks for us to get all the other 3 each of our routs migrated over and then we were able to turn it off for all users and that made
us really happy because then we were able to start deleting some backbone could buy all the old backbone bacanals run use Zuse deleted and we feel like we're on our way so
once we had these now a 32 year outs in place each 1 wrapping a single backbone yeah each 1 with its own component each component wrapping single backbone to assign are rewriting no those backbone views and putting logic into number but before too long we start seeing pull request to
look like this they were enormous they were too big to DOS to beta Review too big to know make the changes incrementally quickly so what was going on so we thought we were living in a world like this where you had 1 component wrapping 1 view once we dug into the back of a little more you each view is really Corning's many child use and there's no just a lotta logic in there so we did what you do when you have a problem is too big to handle and we broke down to serious smaller problems so we realize if we could wrap each of this child is and then replace you know that coordination from backbone in number now we've had no smaller farms and just we write each component 1 at a time until we're left with a clean amber pure amber amber only solution so that's how we re read the letter but what about the data right we did my idea was backed on models B 1 a data models so we had to also rewrite the and a model player and you know we thought we had done a really good job design API there we really consistent but once we moved into an EMBA data land which really pushes toss a consistency in anything it's not you conventional it you got a fight amber data and we realized we weren't so you know we usually had route elements the not always we sometimes had 2 different you also serving same resource and often with with a slightly different attributes coming down and yes euros non RESTful and you know we built our own homegrown errors and pagination the solution so we're able that works for all these problems but there is pain and now we surpass ourselves should we just we write our API is in something like Jason API a draft you well know something conventional and now the answer was maybe we should but not right now that we want to you know keep our focus on deleting backbone code and we're was a good idea but was helplessly backbone could so you know basically we had a list of tactical that to we get to later and we put on the west and we moved on with the existing API and now we were in a place where we had
a system and we could work through these components 1 at a
time and tackle them and make the changes so so that was all
good now I want you switch gears a little bit and talk about some of the other problems we had made no made extracted all those different applications so 1 of the applications we have or steadily application
where it now needs cattle patient visits see who's coming in for the day and no really common use case was to go from the skeletal into a patient's spatially back to the steadily you go back and forth a lot and at the same problem we had before where you're leaving number up loading a new amber after leaving number uploading new umbrella right so the same problem that being slow in the past when everything was sort of slow now users notice but did notice a huge amount as we migrate more more and amber and the emperor apps are getting faster users didn't always notice the app going faster they noticed the things that remained feeling slower so we knew we had to tackle this problem and this is where we decide to take that shirt the sheep and the troops settling up in combined together into 1 triple and so you know the problem we had when no combining 2 apps dissimilar the problems you have when you're emerging to get branches right as I have no complex because super smoothly but any time the complex you know you're in a world of pain so where you know where we see the complex the 1st place we saw complex which is in our own code so that could be now any now and the code we wrote now routers models components and pretty much if you had the same thing that was named the same way but was not exactly identical that substantial conflict so for example you know both of these 2 apps had a patient details page and in their face sheet right the patient details display pretty much everything about the patient whereas in the scuttling have the displayed just a little bit about the patient and a link over to the k she's page so we realize that we could do before merging them with just a name space each them different and so calling on both patient details we call them now we name it's it's a face she patient details and social patient details that way when the merger happens there's no conflict you wind up with 2 separate components and again you know somewhere down the line we can decide Hadamard you had actually combine them if they really are doing the same thing so the other place we saw conflicts within our package Jason and know immediately we realized things like amber JS Gray had to be in the same version in both applications but what surprised us was there were other packages there were only in the face shape only in scheduling and that we didn't think would causing problems but once we combine them both into the same packages and there were no surprise in conflict so we can expect so the way we solve that was to just you know basically add all the missing packages from 1 application to the other and vise versa until we wound up with few package Jason's were identical in the original apps and then emerge to go through smoothly in this case are having a really good test we help now saved our bacon terms of knowing know when things failed and working through them in small pieces rather than now a huge thing where everything's broken God knows why so you know so we were able to do the more successfully and it went really well but now it again it's a distracted us from deleting the backbone to and settling case it was really important right the users were feeling real pain and was the right thing to do but now we had a bunch of other apps and we did wanna pay that price of doing the merge and spending all that time on it instead of doing back code so we wanted out was there a different solutions so we came up with you know an old favorite an old
no not a favorite the I frame you know we realized if we built a component that had an I frame and and we changed know those other apps to be scanned so they would fit nicely in this red box was no nap or anything like that now this component could just loaded a brand new other application inside of it so this is the approach we went to I know to merger to fake merge all of our other applications now the last thing I wanna talk about
is how we stay motivated over time so you know we worked on this project for a a little over a year and no year is a long time so we know came up with a bunch of different techniques that help to stay motivated and the first one
was drawing a pretty picture so what we did is we wrote some scripts which is cannot know the number of bytes of backbone could not have the number of bytes of 2 and and yet every Monday morning we ran that script and updated this chart so that we could see over time you know the red bars going down we were deleting backbone and again right made us feel good to know that we're on the right track here in fact you know this chart you know I made this chart my homepage that I'd come in and sit 1st thing and usually exciting and if you look closely server over in the bottom right corner were this closer lady getting you know the last of that backbone out but didn't quite make it in time for today so the 2nd thing we did is we defined what we were doing in business terms so we said now a core goal of our Camus' speed up our ability to deliver changes trip and the reason for this is in a tactical initiatives often get d prioritizing forgotten about compared to the user-facing and and initiatives so and then I did happen to us but having this written down in black and white and serve agreed as a choral our team helped us now whenever that start to happen was to know reprioritise and bring it back into discussion instead of being forgotten about forever any on the flip side you know it can
be exhausting as an engineer to work on technical cleanup for a year so over this time now we kept shipping features we know we can only work on this we also did stuff to help users and to make better and no in fact some more midway through the year the users in our product team so again excited when they saw that changes were becoming easier right it became faster to make these changes in Missouri getting payoff in doing this yeah and the last thing we
did and this nicer mention we're talking about API redesign where the I frames is things that were not part of our core goal of deleting backbone could we know shamelessly put them on a title that list of things to get to later and not so far it's worked out well for us in that you know it hasn't been a black hole of things that just get forgotten about and we have circle back to them and taking care that went on and on so where are we today
and basically up over the last year we have swapped out our entire front end application from underneath the users here for the most part without them notice and so Gaston really good and
today you know we have about 95 routs 75 models in over 200 components which now I don't know if that feels like a big to you it feels pretty big to us and now know how we did this was just by remembering that in the end today we're aiming to words having a nice clean by really focusing on the small incremental releases by reusing as much of our backbone cos we could in the beginning by rewriting 1 component time by yeah deferring everything that was off the critical path of deleting backbone could we also help focused on simplifying architecture so we wanted and of 1 application 1 technology so it's so much easier now that we know what we have to work on this codebase we can go in and think amber running go in and think was this the backbone piece of the marionette piece peaceful react so so so much easier to do that and then all those tricks as talked about ready help us stay motivated and keep the momentum as we went the course I'm
standing up here today It's now thanks to the whole team who worked on this that we got it done thank you guys very much the
and that this that what
happened I mean you can do
the happen
Videokonferenz
App <Programm>
Binder <Informatik>
Kartesische Koordinaten
Zehn
Subtraktion
Architektur <Informatik>
Punkt
Quader
Mathematisierung
Zahlenbereich
Kartesische Koordinaten
Physikalisches System
Biprodukt
Framework <Informatik>
Quick-Sort
Homepage
Übergang
Entscheidungstheorie
Scheduling
Prozess <Informatik>
Programmbibliothek
Schnittstelle
Autorisierung
Lineares Funktional
Architektur <Informatik>
Wellenpaket
Prozess <Physik>
Sichtenkonzept
Mathematisierung
Impuls
Zahlenbereich
Routing
Kartesische Koordinaten
Bitrate
Sichtenkonzept
Code
Ordnungsreduktion
Informationsmodellierung
Komplex <Algebra>
Rechter Winkel
Mustervergleich
Zusammenhängender Graph
Projektive Ebene
Figurierte Zahl
Videospiel
Bit
Code
Skript <Programm>
Code
Router
Bit
Browser
Zahlenbereich
Schreiben <Datenverarbeitung>
Element <Mathematik>
Homepage
Komponente <Software>
Knotenmenge
Informationsmodellierung
Hook <Programmierung>
Mustersprache
Mapping <Computergraphik>
Programmbibliothek
Router
Zusammenhängender Graph
Informatik
Kraftfahrzeugmechatroniker
Sichtenkonzept
Default
Datenmodell
Volumenvisualisierung
Routing
Sichtenkonzept
Ereignishorizont
Quick-Sort
Office-Paket
Funktion <Mathematik>
Last
Rechter Winkel
Caching
Mereologie
Tabelle <Informatik>
Router
Bit
Hash-Algorithmus
Quader
Mathematisierung
Zahlenbereich
Kartesische Koordinaten
Code
Homepage
Task
Hash-Algorithmus
PERM <Computer>
Zusammenhängender Graph
App <Programm>
ATM
Dicke
Hyperlink
Default
Routing
Physikalisches System
Instantiierung
Binder <Informatik>
Funktion <Mathematik>
Last
Mereologie
URL
Instantiierung
Tabelle <Informatik>
Fehlermeldung
Sichtenkonzept
Güte der Anpassung
Mathematisierung
Element <Gruppentheorie>
Datenmodell
Einfache Genauigkeit
Zahlenbereich
Routing
Element <Mathematik>
Sichtenkonzept
Mathematische Logik
Fokalpunkt
Code
Komponente <Software>
Informationsmodellierung
Wurzel <Mathematik>
Rechter Winkel
Prozess <Informatik>
Zusammenhängender Graph
Koordinaten
Widerspruchsfreiheit
URL
Fehlermeldung
Attributierte Grammatik
Bit
App <Programm>
Mathematisierung
Kartesische Koordinaten
Zusammenhängender Graph
Physikalisches System
Bit
Quader
Versionsverwaltung
Nichtlineares Zuordnungsproblem
Zahlenbereich
Programmschema
Kartesische Koordinaten
Dienst <Informatik>
Term
Komplex <Algebra>
Steuerwerk
Code
Homepage
Komponente <Software>
Informationsmodellierung
Code
Zusammenhängender Graph
Gerade
Inklusion <Mathematik>
Softwaretest
App <Programm>
Shape <Informatik>
Namensraum
Raum-Zeit
Verzweigendes Programm
Telekommunikation
Binder <Informatik>
Einheit <Mathematik>
Komplex <Algebra>
Rechter Winkel
Grundsätze ordnungsmäßiger Datenverarbeitung
Nichtunterscheidbarkeit
Hadamard-Matrix
Modelltheorie
Weg <Topologie>
Subtraktion
Mathematisierung
Skript <Programm>
Zahlenbereich
Speicherabzug
Projektive Ebene
Term
Kreisfläche
Rahmenproblem
Rechter Winkel
Mereologie
Mathematisierung
Speicherabzug
Mailing-Liste
Biprodukt
Impuls
App <Programm>
Kartesische Koordinaten
Komponente <Software>
Rahmenproblem
Informationsmodellierung
Code
Mereologie
Debugging
Zusammenhängender Graph
Wort <Informatik>
Computerarchitektur
Modelltheorie
Ganze Funktion
Hilfesystem
Mittelwert
Klon <Mathematik>
Binder <Informatik>
Quadratzahl
Sommerzeit
Datensatz
Datentyp
COM
p-Block
Shape <Informatik>

Metadaten

Formale Metadaten

Titel The Chirpolith: Successfully Migrating A Mess App to Ember
Serientitel EmberConf 2018
Autor Rothenberg, Alex
Lizenz CC-Namensnennung - Weitergabe unter gleichen Bedingungen 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen und nicht-kommerziellen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen und das Werk bzw. diesen Inhalt auch in veränderter Form nur unter den Bedingungen dieser Lizenz weitergeben.
DOI 10.5446/35700
Herausgeber Confreaks, LLC
Erscheinungsjahr 2018
Sprache Englisch
Produzent Confreaks, LLC
Produktionsjahr 2018

Inhaltliche Metadaten

Fachgebiet Informatik

Ähnliche Filme

Loading...
Feedback