So Long, Hoboken
This is a modal window.
The media could not be loaded, either because the server or network failed or because the format is not supported.
Formal Metadata
| Title |
| |
| Title of Series | ||
| Part Number | 4 | |
| Number of Parts | 94 | |
| Author | ||
| License | CC Attribution - ShareAlike 3.0 Unported: You are free to use, adapt and copy, distribute and transmit the work or content in adapted or unchanged form for any legal and non-commercial purpose as long as the work is attributed to the author in the manner specified by the author or licensor and the work or content is shared also in adapted form only under the conditions of this | |
| Identifiers | 10.5446/30703 (DOI) | |
| Publisher | ||
| Release Date | ||
| Language |
Content Metadata
| Subject Area | ||
| Genre | ||
| Abstract |
|
RailsConf 20154 / 94
1
4
7
8
9
10
11
13
14
16
17
19
21
24
25
29
30
33
34
35
36
37
39
40
42
47
48
49
50
51
53
54
55
58
59
61
62
64
65
66
67
68
70
71
77
79
81
82
85
86
88
92
94
00:00
Universe (mathematics)QuicksortExtension (kinesiology)Category of beingWebsiteSocial classMultiplication signFrequencyCollisionVideo gameRight angleRevision controlBoss CorporationPhysical lawMereologyGroup actionArithmetic meanType theoryDisk read-and-write headContent (media)Decision theorySeries (mathematics)Well-formed formulaSparse matrixSource codeHuman migrationService (economics)Cartesian coordinate systemFluid staticsBitDifferent (Kate Ryan album)Term (mathematics)NumberData managementOptical disc drivePerspective (visual)Musical ensembleComputer architectureInformation securitySoftware developerCore dumpMobile appRewritingLine (geometry)Parameter (computer programming)NP-hardCodeVideoconferencingBlogImplementationStatement (computer science)WhiteboardSoftware bugDampingSuite (music)Computer animation
07:29
TheoryMedical imagingWordMereologyProduct (business)Service (economics)Network topologyOrder of magnitudeMathematical analysisMultiplication signAddress spaceVirtual machineGoodness of fitJava appletElectronic visual displayWeb 2.0InformationComputer architectureINTEGRALLevel (video gaming)IntServHome pageFault-tolerant systemData storage deviceCartesian coordinate systemQuicksortRange (statistics)Suite (music)Process (computing)Computer configurationHuman migrationWeb pageSoftware developerSoftware frameworkConnectivity (graph theory)Computer animation
10:15
Right angleGroup actionSpecial unitary groupUniverse (mathematics)Time seriesConnectivity (graph theory)WorkloadResultantParameter (computer programming)MereologySound effectStudent's t-testTheoryDisk read-and-write headExecution unitMusical ensembleSet (mathematics)Order (biology)Fourier seriesSoftware testingProduct (business)Multiplication signPower (physics)Electronic mailing listMoment (mathematics)Vector spaceForestObject (grammar)AreaWebsiteWater vaporSlide ruleWordQuicksortProcess (computing)Line (geometry)Position operatorAtomic numberArithmetic meanService (economics)NumberRule of inferenceTheory of relativityPresentation of a groupSystem callBit rateSocial classInstance (computer science)Goodness of fitFocus (optics)Point (geometry)Revision controlSolid geometryTouchscreenFamilyInsertion lossLevel (video gaming)Binary code1 (number)Inverse elementGraph (mathematics)DigitizingLibrary (computing)CASE <Informatik>Category of beingFlow separationCodeAddress spaceMobile appWeb pageSemiconductor memoryTrailDifferent (Kate Ryan album)Game controllerConfiguration spaceComputing platformBlack boxCuboidComponent-based software engineeringRoutingHuman migrationHash functionService-oriented architectureCartesian coordinate systemArithmetic progressionContinuous integrationValidity (statistics)DatabaseSuite (music)Computer architecturePoisson-KlammerContent delivery networkProjective planeModal logicTerm (mathematics)Spur <Mathematik>FeedbackAutomationBitFluid staticsInformation securityPattern languageMathematical analysisGraphical user interfaceScaling (geometry)INTEGRALComplex (psychology)TelecommunicationFunctional (mathematics)Self-organizationPhysical lawStandard deviationComputer fileControl flowStress (mechanics)Task (computing)Figurate numberComputer configurationMonster groupLink (knot theory)Test-driven developmentView (database)Front and back endsQuality of serviceBridging (networking)InformationMappingUniform resource locatorStructural loadElectronic visual displayUsabilitySoftware developerFormal languageCommitment schemeContent (media)Block (periodic table)Associative propertyConfluence (abstract rewriting)Orientation (vector space)Computer animation
Transcript: English(auto-generated)
00:21
It's hard to read on this slide, but you'll see the gold medallion, turns out I'm a King certified red bear, and I was at the Tuxedo Park Renaissance Fair last summer, and it turns out I'm pretty good, I have to recognize it, I'll try to do that, I'm not going
00:40
to do it here, but yeah, I get to write through being JavaScript. I write a fair amount of Clojure on the side, a lot of website writings, and I work hard on Ruby and Rails. I started with Rails about three years ago, and then took a sort of a detour through Sinatra,
01:02
and I'm coming back to Rails, which has been an interesting journey, and I think it forms the migration that you're going to hear about. Another thing, so if you're heading up, and if you like Ruby, and it seems like most of you are, I put out a book late last year called Ruby Whispering, and the great
01:23
folks at No Star App set up a promo code, so if you're interested, you know someone who would be interested, if you go to the No Star App site, and you use the Rails promo code, that's just 40% off. So if you are familiar with the book, if you're interested, please come find me after the show, if you don't like it, please direct all the invites to my publisher,
01:51
onto the show. The obligatory caveat, there are no silver minutes. There's no way to see it, the migration is not a cure-all.
02:02
It's not a do-over button, but this. You should always be skeptical of anything that reports to a blank, we'll fix this, whether it's language, technology, framework, way of doing things. Rewrites and migrations are really fun. They're also really hard.
02:22
So they should never be undertaking lightning, and they should be undertaking with the understanding that doing your own thing is unbelievably easy. It's very easy to paint yourself into a corner, it's easy to start rewriting without knowing where you're going, and so planning, thinking, and doing are very meticulous and very thoughtful things that you should be doing.
02:47
So I'm thinking, why do we want to do this thing if it's so dangerous? You might have talked to business stakeholders, folks with products, and you had to say something along the lines of, I promise that if I do everything exactly perfectly,
03:01
nothing will be any different, and the odds are good that things are going away. So that's kind of hard to get by, it's hard to say. The best thing that could possibly happen is nothing. Or at least from the perspective of the user. There are a number of code-related reasons to migrate. Manage complexity, this is what we do every day.
03:20
Different or better tooling in terms of gems, external services like Codify that you're not familiar with, static analyzer, looks at duplication, complexity, things like that. So we're out of band. Things that we should think of as in-band. We don't think about security necessarily, or maintenance, or devops. While we're writing, we're thinking about the code.
03:40
But these out-of-band items are crucial and are things that we need to think about in our long-time to read these devices. These can be improved or made easier via migration. Another one is application performance. So we hear a lot about Ruby applications and their performance. We think about how your Rails application is structured, how your soundtrack application is structured.
04:01
In our case, the applications, the suite of Rails apps, do a lot of floating and reloading while we're floating. So thinking about how your application can be improved by moving to a new code base isn't working. At RTR, we inadvertently badly implemented half of Rails, which we lovingly dubbed Ruby on Rocks.
04:23
This is what it was. We have helpers that were sort of like Rails helpers, but not. We have code that sort of tried to tease apart some controllers, but didn't. At one point, we had a weird board with an asset pack that was nine months out of date. You can make it a whole person in nine months.
04:42
So the bugs and the features and the things that we're missing that we're behind on that we didn't know about were crazy. And it pinged out really too. Like, how we're managing versus DHH is managing. And it turns out there's a lot more literature on DHH is managing. And it's much more well understood.
05:01
But there are also sort of people reasons to migrate. We had difficulty kind of working in source. When you're using Sinatra, if you're familiar, it has far fewer opinions than Rails. Unless you're working on Sinatra, or say, it's very hard to write tooling that's not somehow coupled to your implementation or to your business.
05:23
So the tools that we were using, we thought about open sourcing would have required a tremendous amount of work to get into kind of a general library statement. And further, Sinatra is not as widely known, widely used, or maintained. The community is much smaller. Literature and development are also much better and easier to find for Rails.
05:46
So blog posts, tutorials, videos are easier to find, a lot more literature, a lot more conflicting opinions, but in a lot of ways complementary opinions. So you can have a more informed decision and a more code base by looking at that.
06:02
Development performance is also important. Getting spun up on Ruby on Rocks is very difficult. It takes a while. You have to find out why we did what we did. It made sense to somebody. Some of those people are still there. Maybe they were gone. There's some documentation, but it's from the roll of last year. It's clearly not kept up to date. Some of its arguments are made by someone who's desperately trying to figure out how this spoken Sinatra application works.
06:27
And so working with something like Rails will make it easier to say, hey, this is how Rails does things. We follow those guidelines. And so if you look at this, it's going to look like a Rails application. And finally, hiring. It's much easier to hire.
06:41
Ruby developers who know Rails are familiar with Rails. If you've seen a Rails application, you come to a new one. You're generally thinking you're not going to get a lot of surprises. It's much easier to find Rails developers than it is to find weird bespoke Sinatra developers. And it really comes down to the fact that every tech problem that you have is probably in its core a people problem.
07:01
So these people problems were coming up again and again. There's a problem with the way you use education when you're hiring. And we realize that moving to Rails will help us with a lot of this. So let's say you're buying what I'm selling. You say, okay, we're going to migrate. What happened?
07:22
So they want to know a little bit about the RTR architecture. So it's a service oriented architecture with background and React on the client. A lot of background and React components are a bit new.
07:41
I think they're going into production in the next few weeks. But there's been a lot of good in-house adoption. I think there's a lot of excitement. The web layer is Sinatra. It is migrating to Rails. These services are Java services. I think a couple or six. Most are seven or eight. The framework is Java.
08:02
And it's really delightful to write Java 8 in Java. You're probably surprised to be a Rails company. You hear someone say Java and delightful in the same sentence. But it's absolutely true. So if you use Java, you weren't sure you liked it, or you're using Java now and you're interested in ways to maybe make that development process better,
08:22
I highly encourage you to get Java 7. The data stores are MySQL and Mongo. Obviously with that, you're going to get a wide range of both. And Ruby's Mac is kind of a single application, but are in fact a suite of 12. There are 12, maybe 14, actually a small amount of applications that were in concert to serve the web page,
08:42
or to serve dev.web.dev, dev.web.com. We originally designed this way for the sort of fault tolerance and fault isolation. The idea being you could, let's say you're on Good Morning America, tons and tons of people are going to go to the home page, but they're not going to convert it. They're not all going to go to the grid and do the address. They're not all going to click on individual addresses
09:01
until they write something global. So you could scale up machines that are running. Just the home page is all that machine, independently of the other parts. The problem that we found was that this kind of swim laning was at the wrong level of granularity. All of these front-end components, most of them shared the same back-end services.
09:23
And one back-end service, especially if it was an integration service, was powering a lot of them. So if the user data, the user information integration service there went down, none of the personalization would work. Logging wouldn't work. You couldn't see anything that was unique to you on the product display page, on the grid, on the home page.
09:43
If the product services went down, if there was an integration service for that, nothing's going to come through. Neither the grid nor that product display page are going through. And so we realized that we sort of not achieved what we wanted with this swim line architecture. And that it might make sense to move everything into this.
10:02
It was really a hard one application, serving traffic. There was a tremendous amount gained by separating everything out to the extent and in the ways that we have. So there are a couple of options if you're thinking of migrating. They're actually probably important to you, but we thought about it too.
10:21
The first one was mounting. So the idea here is you take your Rails application, you mount all of your Sinatra applications inside of it. Rails then does all the routing. Someone says, I want to go to the home page, and do all the routing to the home app. Someone wants to go to this grid page and make great addresses. It'll send you to the grid app.
10:41
The problem here is, well, let's talk about pros. Pros are you continue to keep separate units of code separate. Each former swim lane is housed inside of Rails. And you continue to do what it always did. The only difference being it's now, you know, Rails S, or you're starting Rails and not starting. You want to lose that uniform configuration. The work of switching Rails is done in front.
11:00
You go through, you bite the bullet, you update all your navigation jobs, you change all your automated stuff, you go through all your new scripts, something like that, and now you're all yours. And you've got to pat yourself on the back. We're a Rails shop now. But the problem with that, at least in our case, was performance. We had to load both Rails and Sinatra. So Rails would load,
11:20
Rails would pull in a bunch of Sinatra applications, Sinatra would load, it would do all the nice tracking. Due to the way we had done certain things like content and view helpers, those classes would be opened and reopened and reopened and reopened over and over with more methods and shoved into them, as each ensuing Sinatra application would be able to play. There's also, again, it's sort of nice
11:40
that you're biting the bullet and now you're on Rails. But you're not really, and this is kind of an early commitment. So now if it doesn't work, it's kind of too bad. You're on this path, you're going to go to Rails, whether you realize somewhere along the line, maybe it's something else with a surprise. And I think that's the important part of a migration like this, where you should go to Rails, and Rails is what you need,
12:00
but really, you're migrating some code and it's long past something like Rails. There's a good confluence there that's working well. Rails is an amazing tool. If at some point you say, listen, everything that we needed, now we have. We're all set. There's no reason to keep pushing. There's no reason to adopt Rails or any technology. Just been sitting using that technology.
12:22
And again, this is not true, but it'll up front cost, but we're making a switch. So the second way of doing this is via the Strangler pattern, which is the way we adopt it. The idea here is you, and it was kind of a modified Strangler, and by that I mean you have a code base that's in one framework,
12:40
but the language is the same, but the ideas are the same. And you want to convert it into a new one. Now back in the day, maybe three or four years ago, right the right way was a Drupal. I felt the disturbance of the force, you guys heard that one. Yeah, it's about as bad as you think. Possibly worse.
13:02
But the nice thing about that was we sort of strangled our way out of it. So we said, okay, this part of the application, this doesn't belong to Drupal anymore. Here's a new Sinatra application that handles that. And now we're going to take this and break it all away from Drupal, and now Sinatra handles this. You've got to keep carving out things that the old application no longer does,
13:20
new application applications take over, and that's a very effective way of getting out. For Sinatra to Rails, what you can do is sort of evolve your code base, kind of warn it to look more like Rails all the time, and then when it comes time to separate your verticals and say, okay, well, the PDP, product display page, individual address, is now served by Rails.
13:41
We just send that traffic over there, and we can just drop our modified Sinatra code in, remove a little bit of scaffolding, and it will just work. We can do the same thing for the homepage, or the grid, or accounts, or user stuff. And it's much more drop and drag and drop, which is nice. So this is the pattern that we call. So the pros are that you don't have to do a load
14:00
of Sinatra and Rails anymore. You continue to run the modified Sinatra, and Rails kind of runs next door, taking more and more traffic. The nice thing is, you're kind of different at the moment. So maybe you get to your modified Sinatra setup, where you get to a grid over something, and you're saying, you know what, this does everything we want. Everything we could possibly have hoped for or asked for,
14:20
at least for now, is panning by this code base. So we don't need to migrate all the way to Rails. And that's not a bad thing. That's not how this story's going to go, I don't think. And the nice thing about the team at Rails is it sort of ease developers into Rails is what it's doing here. There are a number of front-end engineers,
14:41
JavaScript and Ruby, and most of them use Rails, but not all of them. So getting people spun up who have not used Rails before is sort of not trivial, but doing it is what makes a nice Sinatra. The cons, as I said, is a double-edged sword of different commitment, because it's easy to do the first 80%. And it's easy to convince yourself you have this nice, fixed
15:01
Sinatra suite. It's easy to tell yourself, you know what, I'm done. I am actually okay with what I have. And you might not be. You might have more stuff to do than deferring working on that second 80% because that's what a lot of stuff is. So you have to be aware of that. And that plays into the amount of team discipline
15:21
that this requires, not only because of that, but because you're deferring and doubting Rails' opinions for so long. You're relying on your team to metamorphose this codebase in a way that makes sense. And it's all based on port requests. It's all based on codebase. It's all based on someone having the strength to say, hey, actually, that's not how Rails
15:40
is going to do this. I know this way is easier, but here's how we should do it. And doing things the right way is hard. Automating that away is the ideal way. But oftentimes, it just comes down to discipline and to culture. So you have to discount that aspect. And finally, this just prolongs the experience, doing this kind of metamorphose
16:00
and then switching to Rails. It extends the amount of time that your codebase is this weird special stuff like. And that's tough for everyone, especially team hires who come into this half you know, this Frankenstein monster type, you know, summing together half, you know, composed thing. And some parts are really, really great and you kind of have to warn them to get this part maybe
16:21
maybe stay away from them. So we had those two options. Those were the options we whittled it down to. So how did we do it? Step 0 is test. I can't stress this part but if you don't have superb test coverage, there's no way you can do this anymore. There's absolutely no way
16:41
you can commit to this kind of coverage tomorrow. So at RCR, we had RSpec create tests RSpec will load up for some of the integration tests making sure that different components talk to other components properly. Our black box slash smoke UAT testing we had a large kind of old water suite that was
17:02
run via Jenkins and through the process of moving that over to Capacara. Partly because Capacara is newer as kind of the standard. Also because as you're doing this you kind of want to make sure the tests that they code are evolving side by side or rather the tests are evolving just ahead. So you can say, yep, everything looks great on the site right now. And yep, everything
17:21
looks great on the site when we move this part of functionality over to Redis. When we started using CodePilot as I mentioned before integration, not integration sorry, for duplication complexity kind of static analysis making sure it just worked okay. If you're not familiar, CodePilot is on a scale of
17:41
4.0, so it's a good GPA. RCR's GPA was 0.67 which is as you might guess, bad. When I left RCR a couple weeks ago, it was 2.1. It was improving all the time. So I was very excited. We got to see students. I have no doubt
18:01
it's going to be these students pretty soon. Likewise you need to test coverage with probably around 50%. We're just going to have a false sense of security. A lot of it was kind of like part of 200 OK, yep, 200 OK, yep, 200 OK. And it's kind of, it makes you feel like you're testing more than you are. We strict some of those out. We put in more robust, correct tests it's around 84-85%
18:22
and again, getting better over time. Having these tests are part of it because it's necessary for any kind of migration because if you don't know when you progress, there's no way to make continual incremental feedback. The word on automation, it absolutely will save all your chunky
18:41
vegans. It's essential for continuous integration. If you get to continuous delivery, if you get to continuous deployment, these are automations crucial. There's no way to get there without that. So, you want to automate as much as you can. Quickly, I'll just outline how the roadway does this.
19:02
Whenever there is a check, check, check or recommended feature, you push to get it out, you make a pull request. The pull request triggers a chunky jump, which is going to mint and test for the JavaScript. It's also going to trigger code climate, which is going to look and say, okay, this is at least not any worse than it was. Or it will let you know, hey, actually this is worse.
19:22
There's no way to write a non-trivial application and not introduce complexity. So, sometimes it's okay, sometimes you look at the pull request and say, look, this is more complex but it sort of has to be more in the middle of migration, it's going to get worse before it gets better. This is sort of what it is. After the give or give green, hopefully on the pull request, check things,
19:41
you get a plus one on your pull request, it gets merged, and then every day a tag is cut off of master, that tag is tossed off to QA, once that tag is there, both manually UAT, so actual human beings looking at the site, making sure it doesn't expose to, as well as the smoke tests, those kind of copy bars you put through that test are run, get both of those
20:02
come back every day. We can do one. The pulling takes a couple of minutes instead of every day. And then after that, the same smoke suite automated suite is run in production, just to make sure that everything looks okay. As you can imagine, the CDN could be weird stuff there could be asset mis-compilation, there could be differences because you have some code
20:20
that does something with the bracket mark in this production as opposed to test things like that. So, that's sort of a step-by-step how you can set up a pipeline to make sure you're continually testing continually running everything and making sure it's okay. And the speed's okay, the pipeline's okay.
20:40
So, step one, models. The first thing that we started doing and is very much in progress is converting these 3D classes into Rails models. So in our case, because of the service-oriented architecture it's converting service calls into models. Ideally,
21:01
if you do this correctly to your Rails app, it doesn't care if the model is being constructed by a quality of service or a quality of database. What it gets, you can search, query, use, validation is what I call that stuff. So what you do is A, you have a robust set of models created for your service calls and then B, you incrementally
21:20
add in these useful gems that Rails offers you. And the really nice thing about Rails is that it really is kind of a box of components. We think of it as a monolith, we heard about monoliths today. But in many ways, it's not. You can, for example, we're using the asset pipeline with Synopt. That is a component that can be used independently in Rails. Active model, active record, active support
21:42
these all can be used without having to go into Rails proper or commit completely to Rails. The nice thing there too is you can kind of incrementally become Railsier and use that in the platform of operation. And for us, honestly, we're even using models, we're just passing hashes around. And if that sounds crazy here, not wrong.
22:02
It was difficult. You have JSON commit to the service Ruby layer will convert to a hash and then sort of pick what it wanted and then pass the hash to somebody else. This is bad. So building models for service calls increased our memory footprint. We had an interesting few days where we were trying to figure out where all these extra objects were coming from.
22:21
And it turns out it was because we were programming correctly. And I'm not entirely sure I'd buy this I just had a few things with the process of creating objects and orienting our code around them. But it seems to be working, so I'm not going to knock it just yet. Like I said, this is kind of underway right now.
22:41
The next step is the controllers. For Sinatra to Rails, this is the dream part. Because Rails does not, sorry Sinatra does not actually separate clean routes from controllers. It sort of associates blocks from routes and then executes the controller actions inside them. So there's not an easy way to go about saying
23:01
these are our routes, these are our controllers and this route, when you do this action, then it would occur as it is. So what we did was we mapped the existing routes because what we had is not correctly responsible or resource oriented. The existing routes were mapped to branch routes. And then we begin bridging
23:21
these routes these route controllers over to true routes controllers. So we created a rule knock. At the end of the day it sort of looked like if you had a rule-ified break routes, like that's what you got sort of every resource you had all the URLs. So here this actually maps to indexes, maps to edits, et cetera, et cetera.
23:42
Here's an example of the code. Credit actually goes to the individual John Bolden, who I wrote his point of watch with, who actually wrote all the magic that makes this work. So I put the gist and his comment info on the slides when they come out from SlideShare. But the idea here is you have an app that interacts
24:01
with SinatraBase, you extend it with these rails and bridge controllers, and then you can do this magic where it's rails route, get, a route, and you map it to a controller, and this does exactly what you think. You go and you have a test controller shot below, it is what you get. Likewise you can pass your parameters with slash hello comma name, comma whatever,
24:22
and those parameters are passed along. And then you can just write real rails controllers. You can just take a look from what you would find in a rails route. And like I said, when you start actually dropping over, you don't have to do any weird buttoning, you don't have to say, well, this is sort of like how Sinatra is thinking about this, how do I make it up as I go?
24:41
You already have these securely defined routes and controllers, and you can just start to make them over. But like I said, this is the hard part. This part is a little easier, but it's deceptive. So for the views, it's mostly moving data around, mostly putting views partially into the data where rails expects to be on them. The problem is that it's deceptively dangerous,
25:02
right? It's very easy to make typos, to make errors, to put something in the wrong spot, to forget to move something over, and then you could end up in a situation where it's part of the codebase, the user doesn't go very often, you don't look at it, UAT doesn't look at it, it's all the way to production, someone goes to the start part of the codebase, and all of a sudden
25:22
it just crashes. There's just no room. So this is something that you have to be very diligent about. It's something that you have to have come into running hopefully and running often, and going through it, looking at everything. Ideally, if you find something like this, you immediately add something to your integration, to your UAT testing, and have an article
25:42
that prints, like, oh yeah, this is here. This doesn't bite you too badly, you do have really strong black box testing, but again, you can get you in it. Finally, it's really just leveraging Rails, using Rails as helpers, kind of deprecating your own helpers, which
26:01
we've already done a lot of pseudo-form helpers that kind of look like Rails helpers, but not, and it's going to be very nice to deprecate those in favor of the Rails ones. And the last step here is going to be all the not-so- small things, so cutting up your break file into slash link tasks, going through, making sure
26:21
that you're using kubecton, that's great, it's great for complexity, it's great for duplication, but you haven't been using any security features because kubecton can't figure out your special stuff like heart pressure, and when you switch to Rails, it's all in one case. You can't say, hey, this is really insecure, you shouldn't be doing this. But again, these things are a little bit out of the way, right? Your break task will still work
26:40
if you have a 3000 line break file. You're not going to necessarily miss the fact that you don't have security stuff because you've never thought about that. And so it's kind of making sure and adding documentation, you can track and say, oh, hey, actually, this is the thing that we want or this is the thing we should change, even though it's working fine right now. We really should do it tonight.
27:00
Doing it right, and doing that second 80% are sort of common themes, and those will come up over and over. This is very much ongoing in terms of the migration. I'd really love to say that it happens organically, but it doesn't. It requires a lot of attention and detail, and it requires a lot of not-civil libraries working. This is where all the
27:21
go-yec happens, you know what I mean? I actually want this. So what are we learning? So this is not, this isn't a subtle thread, but I was reminded a bit this morning that BGH talked about Conway's law. And he's right, Conway's law is a real thing, you guys. So this notion that the
27:42
infrastructure of your organization, of the code router, mirrors the communication channels in your organization is absolutely true. So when you're setting up this migration, you're thinking about who's going to work on it, how you're going to acknowledge it, what is it going to look like. The communication channels of your previous architecture and of the teams that are working to move it are going
28:01
to influence the way that application is set up. And so you need to think hard about how you want to allocate people, how you want to work on this, because inevitably you're going to see the traces of that all throughout your codebase, even in a monolith, even in a single application. Get me aware of the second 80%. There's always more
28:21
work to do than there's going to be. There's always going to be those extra little things where you're like, I feel like we can take that down the road. I don't think you have to do that. You have to do it. You cannot move your whole codebase. You have to get it. There's no good way. Because otherwise you end up maintaining code. You have to explain it to people. Only 5% of it is in the Rails app. But there's a Chrome job
28:41
that doesn't give cards, and it's over here, and don't worry about it. It's fine. It's not fine. You have to have your code. There's definitely people around. We have that. It is terrible. Which is the straightaway pattern we use to create effect. Once you sort of get the codebase out of Drupal
29:00
and into Sinatra, it is effective again getting us from Sinatra to Rails. So I recommend this if you are thinking of doing a migration. It is possible to get through Sinatra to Rails or another Rack app to Rails by mounting, and if you have fewer swim lengths, fewer requirements than we do, that might be the way to go. I think this is certainly
29:21
the least for us the most effective way to manage this configuration. Again, finally, testing and refactoring. These are much more important than Rails for Rails' sake. Rails is an excellent piece of technology. I really like working with Rails. I firmly believe that Rails is the right and goal for this project.
29:40
But it's possible in the middle of migration. You might say, listen, we got to Sinatra++ and it's a lot better. It's got everything that we want. You can declare victory when it's appropriate. But this is kind of a non-answer. It's sort of you have to it's up to you. It's your judgment. You can come before us. And you have this tension of, do we have to look for or are we just kind of done 80%
30:02
and we just don't want to do any more. So as DeepLab, that's an excellent post on moving from Sinatra to Rails. I've been here in the deck. I highly encourage you to do that as well if you're looking into this kind of migration. It's a lot of the same stuff that I just talked about, but sort of a little bit hard to
30:20
move. I guess some interesting ideas about models in particular. I talked about kind of in terms of a service oriented architecture that you can purchase more. So you may be going and talking to someone like a bicycle or a co-service. yeah, never migrate to migrate.
30:40
Do it for the products and for the users because you're growing and you're sort of going to outgrow what you have. Your code base is always going to be sort of a mess so if you're diligent, you'll have kind of like a garden and not a wall. So, that's all I got. Thanks guys.