00:00:12.259
thank you hi everybody my name is Jesse uh I live
00:00:19.800
in Texas and I have enjoyed Portland a lot and congratulations for all of you
00:00:25.140
making it to the end of railsconf I always feel like my mind is just bulging
00:00:31.019
at the at the end of this of these um in Houston at the Houston Ruby grade
00:00:36.960
Brigade I like to introduce Everybody by having everybody say when they first
00:00:43.620
started in rails it seems like a good Touchstone for what you've been through
00:00:49.260
what battles you've fought right um so I'd like you to raise your hands if you've used at least rails 3.2 it
00:00:57.780
should be most of you what about 3.0 2.3
00:01:03.539
uh wow 1.0 0.6
00:01:08.820
u r dhh uh you have the 15 years experience with
00:01:14.760
rails that recruiters are emailing you about uh oh you nice
00:01:20.820
way to go cool so most rails apps don't last your entire
00:01:28.920
career right most of the time
00:01:34.740
they're set aside they become too old they become too
00:01:40.079
much of a pain to make use of but what if they do what if they last forever
00:01:45.360
what if they become these Legacy apps that we read about right what if they
00:01:50.759
are at American Airlines and run for 50 years until they stop running
00:01:56.000
what do we need to do with these apps so that they can continue to provide value so that we can continue to maintain and
00:02:02.579
use them this is a reminder that rails is not WordPress
00:02:08.099
you log into WordPress any version and you can basically press upgrade and it'll upgrade you to the newest version
00:02:15.200
your themes may not work but rails or WordPress would
00:02:21.540
now rails isn't set up that way in rails the code is constantly changing
00:02:28.200
both the internal apis and the external apis the ones that we use when we write
00:02:33.540
rails code they're evolving and they're changing to fit what the best use case of of development
00:02:41.580
is at the time what do we think is the best way to write applications
00:02:49.739
Thomas you wrote this he said code is volatile his first rails commit he was a rails
00:02:55.980
core guy it's no longer in rails so even if you're writing the code that
00:03:01.680
is rails it's going to get extracted it's going to get removed it's going to get refactored
00:03:07.620
this is a good thing right it sometimes it doesn't feel that way but if rails is constantly evolving and
00:03:14.879
getting better then we are constantly evolving and
00:03:20.459
getting better if the experience of writing web applications is evolving then we're evolving and this
00:03:26.819
is a good thing so why would you bother
00:03:32.879
evolving your rails apps so you get new features right you get the cool API features uh if you're creating an API
00:03:40.260
you can make better use of your databases with postgres enhancements that come so there are features that you
00:03:46.980
get the second are security updates this is not a trivial matter right
00:03:53.580
there are rails 0.8 log engines running out there that
00:04:01.680
if anybody found out about them you could just send Json parameters to them right
00:04:07.500
so security updates is a big deal to keep your apps online and running
00:04:14.040
your Ruby language could be at end of life right 1.8.7 does not have that much
00:04:19.680
longer to go before it's completely end of life and and
00:04:25.259
this in and itself is not a great thing to be running on a language that will
00:04:30.479
not receive any updates from then on right now the sort of old rails app
00:04:38.160
Touchstone is a 2.3 application there are a lot of 2.3 applications out there right now just chugging away providing
00:04:45.060
business value there's some high profile ones right GitHub is probably the most high profile
00:04:51.139
rails 2.3 app out there right now and I bet a lot of you have it too right
00:04:57.479
that's why you're in this talk so what do we do with them
00:05:06.000
we're going to talk about a framework that you can use to upgrade your rails apps but first let's
00:05:12.240
go back let's take a step back in time of rails app lore and look at what life
00:05:17.460
was like in a 1.0 app and Beyond so rails 1.0 there's a fair number of you
00:05:22.860
that use this version rjs ruled the world at this point right
00:05:29.400
you had JavaScript that your rails app would control the screen
00:05:36.780
I remember seeing this and being blown away right by the biggest change here
00:05:42.660
was that you'd have rails apps that would update specific portions of a page
00:05:47.759
and then do that cool highlight right the flashing yellow for what was just
00:05:52.919
changed nowadays that's not good enough we need it to constantly Auto make changes based
00:06:00.000
on what other people are collaborating but back then this was great and it really set rails apart right it
00:06:07.020
really set the the notion of JavaScript interactivity forward
00:06:13.199
but this is the code that would exist in the controller page dot replace HTML the
00:06:18.240
ID and then the content that you want it to replace you'd also have link to remote
00:06:24.360
link to function the interesting thing about this is the URL
00:06:32.400
right your view could tell the controller what method
00:06:38.280
that it wanted to execute and then do so by saying the controller
00:06:44.160
name the action and the ID and these would be strewn all over the application right
00:06:50.160
your route file would probably have a single line that was match controller slash action slash ID and that's all
00:06:57.060
that you would ever do your actions in your controller would
00:07:02.580
test if it was a post and then make a make a change um you look back now and you're like
00:07:09.780
what is this what were we thinking but it's a dramatic step forward at the time but right now if you have like this
00:07:16.319
would be hard to upgrade right what about
00:07:22.979
Source control well in a 1.0 application uh it was state of the art to be on subversion so
00:07:31.080
a lot of your older applications may not even be on get right now they could be on subversion or I even just saw one
00:07:38.880
um legit was on CVS um
00:07:44.400
not not awesome so we Flash Forward to 2.3 2.3 widely
00:07:50.220
regarded as the The Grail of rails applications right
00:07:56.160
like very popular very stable and things were good so what
00:08:01.199
did what did a 2.3 app look like well a 2.3 when it launched
00:08:08.160
it did not have bundler set up with it right so you would set up your gems in
00:08:15.660
the application so it would be like config.gem and you'd list your gem gems
00:08:21.300
in and of themselves were a huge step forward from 1.0 the reason
00:08:27.360
is that gems could be versioned right whereas your plugins were not they would
00:08:32.580
just get the cut the latest code from a repository and download them
00:08:37.740
gems could say I want to work for version 1.0 or 2.0 and if they go to three I'm not going to
00:08:43.800
do that because I'm going to stick on this same Gem and things were good but of course this was optional so you
00:08:50.220
have some rails 2.3 apps out there that don't even specify their gems in here
00:08:56.580
they just happen to be installed on the dev server or the uh or the hopefully
00:09:02.519
the production server you just say like require will page Knight and it's just there
00:09:07.740
um this is the active record query interface this didn't change much from
00:09:13.980
uh from 1.0 to 2.3 where you just say like find and either all or one or first
00:09:20.399
and then give it the conditions so everything sort of was off of the find
00:09:25.920
that was your that was your API it was 2.3 is widely right regarded as
00:09:34.920
the Pinnacle of rails development by people who romanticize rails 2.3
00:09:41.459
but the interesting thing is like why why did a lot of people stop at 2.3
00:09:49.140
so what did 3.0 happen what happened in rails 3.0 this was the big merge with
00:09:55.019
Merv and a wide range of changes
00:10:01.800
so the query interface to Arrow changed right this is probably the deepest
00:10:06.899
change in the application so instead of defined with conditions now it's like where's that you can chain
00:10:13.740
together Scopes sort of rule the world
00:10:20.519
and this is good right if you if you're running new applications this is great
00:10:27.480
as compared to the rails 2.x land this is completely different
00:10:35.220
you also got a great abstraction in rails 3.0 suddenly active model
00:10:41.100
became a thing this led to a wide variety of stuff that
00:10:46.740
you can do in rails 3 and Beyond you um it is so much easier to have objects
00:10:54.060
like poor old Ruby objects that you can have in a form this open stuff for like
00:11:01.260
mongoid um so active model was a great thing
00:11:06.480
having an abstraction that active record then depended on it is very cool
00:11:15.180
also a big change was the routes so
00:11:22.079
the concepts are still the same but the syntax completely changed the syntax is pretty cool in real story
00:11:27.600
but it's completely different than 2.3 what about 3.1 well in 3.1 we got the asset pipeline
00:11:37.740
so we have comments in CSS and comments in JavaScript that
00:11:45.380
combine all of our files into one file and the application itself is better
00:11:51.959
right it's faster we're not making 10 to 20 different HTTP requests
00:11:57.899
just to load a single page so the app is faster
00:12:03.420
this was tough right um for me the 3.1 upgrade is often harder than the
00:12:11.640
3.0 upgrade getting all of your CSS and JavaScript to work with the asset
00:12:17.579
pipeline the end result is the file that has the
00:12:24.420
hash of the file in the file name itself so it's fast and new browsers get the
00:12:32.279
new version instantly every time that's pretty much it and that rails 3.1
00:12:38.880
out 3.2 is basically a better 3.1
00:12:43.980
so it was faster uh on for in a Dev environment
00:12:50.100
and we got some cool stuff that we got pluck which I think is very cool so you
00:12:55.500
can use this to get arrays of IDs or arrays of of whatever based on a bunch
00:13:01.920
of queries I like pluck it's better all around
00:13:07.079
and then Mass assignment became a thing it became a thing we started to worry about that you couldn't just take all
00:13:12.899
form parameters and send them to your model especially when you included this with like nested params we saw this on a
00:13:20.279
well-publicized hack into GitHub where somebody used the GitHub save form to
00:13:25.740
Traverse up the tree and give themselves commit rights to rails
00:13:31.079
so what happened we came out and we said okay Mass assignment is a thing let's specify what values are safe to change
00:13:39.420
in something called Adder accessible in the model itself
00:13:46.980
now we're at 4.0 4.0 brings some Wicked awesome postgres
00:13:53.880
stuff if uh if you do one thing after this watch Adam sanderson's talk from
00:13:59.880
Monday on the postgres the features you're already using and it will make you want
00:14:06.120
to upgrade to 4.0 just those features by itself you also get some caching right in in
00:14:12.839
4.0 Russian doll caching and strong parameters so we just learned
00:14:17.940
how rails 3.1 brought us at our accessible and for Mass assignment strong parameters is
00:14:24.720
a complete change in both Theory and execution of how we should handle that problem
00:14:31.019
so strong parameter says let's not do it on the model let's do that on the controller and have the controller decide what
00:14:39.720
fields are permissible in that context to update the model with
00:14:45.360
turbolinx is a thing and overall rails 4.0 the absolute best
00:14:51.779
version I've used
00:14:57.360
so how do we get there there are two ways that we can take an older application
00:15:03.060
and have it become a newer application your users will see it as an upgrade
00:15:09.660
right a new newer version so we can either upgrade by a wholesale rewrite of the application
00:15:16.079
or by refactoring it right rewrite is rails new
00:15:22.680
and refactoring is going through a step of changes to upgrade it over time
00:15:30.120
the decision to rewrite an application is not a technical one
00:15:35.399
right what I mean by this is that it is an organizational decision if the
00:15:40.800
organization has the fortitude to actually rewrite an application if you sit down with your technical team
00:15:47.760
and you have the you're like I want to rewrite this application and I want to remove all of this cruft
00:15:54.420
that came in over time I want to take this feature down that nobody uses I don't want to do this this is silly this
00:16:02.100
time will do it right if you do this you'll likely fail unless
00:16:09.600
the entire organization comes together and is on board
00:16:15.019
in most cases that I have personally seen this is not the way that it happens
00:16:20.579
the way that it happens is the dev team has in mind that they can make better
00:16:25.980
decisions now than they made before because they have more information now
00:16:31.380
but the more information now that they have is they are using different features than maybe the product owners
00:16:38.519
are using or more importantly selling to their users right so the product owners and the people that pay the tech salary
00:16:46.139
are like no I made a sale based on this one feature I know that it has value and
00:16:52.019
so you have this idea that yes I can do it in this amount of time because I'm going to be able to cut out
00:16:57.600
all of this stuff but then the same conditions occur this year than they did three years ago
00:17:05.520
that lead to the same assumptions same products and same features that just have to be rebuilt
00:17:11.400
the definition of done on a rewrite is incredibly difficult because not only
00:17:17.100
do you have to add all of the features that you added once upon a time but it has to be better
00:17:24.600
right the the goal line of a rewrite is so much harder than the goal line of
00:17:30.960
just making it incrementally better so what how could you fail by doing a
00:17:37.740
rewrite if you don't have every single feature it'll likely be seen as a bug it was
00:17:44.700
there and now it's not and now I'm mad what about keeping product momentum
00:17:52.140
if you were to say I'm going to start rewriting now then you have to
00:17:58.260
almost pause development for that rewrite time right
00:18:03.720
and so then you're thinking like I've got to get this out the door out the door off the door but your users aren't seeing anything
00:18:09.120
so they're seeing no changes during this rewrite time
00:18:14.580
in your users like we're talking about they're not going to see anything worthwhile they don't care about your rails version
00:18:20.580
they don't care that you're now on Ruby 2.0 and you were on 1.87 they might care
00:18:26.160
if it's faster but generally what we think is faster users don't care about right if you drop the average mean
00:18:33.299
response time from 500 milliseconds to 250 milliseconds you're like yes I doubled my app and users are meh
00:18:42.240
there are specific conditions in which I I would Advocate a rewrite
00:18:48.240
one is you have PHP on Rails so if a PHP on Rails is an application
00:18:56.460
where the controller has a lot of methods the models have no methods
00:19:04.020
and your views have all of the things so they are long they have nested if
00:19:10.200
statements they are the ones that actually go out and do the article find by ID params of ID and then Loop over
00:19:18.299
them they're the ones that maybe make decisions about where to send routes to
00:19:23.460
this happens when you hire new rails devs set them down and say
00:19:29.400
create um so if you have PhD on Rails you don't
00:19:35.640
really have rails you may consider a rewrite at this point
00:19:42.059
what if you vendored rails and vendored gems I've talked to some people here at this
00:19:47.400
conference that have this exact same problem so they've got a rails 2.3 app they have vendored rails they have
00:19:52.500
vendored all of their gems which means that they are in like slash vendor right
00:19:58.559
uh the rails 1.0 is like freeze rails and what happens here
00:20:05.340
what happens is that if you find that you have a bug or you want to change the
00:20:10.620
behavior of a system you've got app or you've got devs that just go in and change rails
00:20:16.140
they go in and they change gems and what happens at this point
00:20:21.179
if you don't have a pretty accurate change log or pretty accurate test Suite
00:20:27.539
you don't have rails anymore you've got Bob rails right and and this becomes incredibly
00:20:33.900
difficult if that's if the changes are substantive
00:20:40.620
this will become hard to just upgrade rails at that point because you're gonna overwrite your changes
00:20:48.960
so let's say you don't have Bob rails and you don't have PHP on Rails you can refactor by a series of tiny
00:20:55.799
wins getting each of those into production over time so you don't go from 1.2 to 4.0 the
00:21:04.500
title of this talk notwithstanding you go from 1.2 to 2.3 and 2.3 to 3.0 and
00:21:10.620
you get to a series of stable points get those into production
00:21:16.020
get feedback and continue on in addition you can add features for
00:21:22.260
your users at each of these points so you're continuing to add value
00:21:29.280
so what are the main upgrade panes in taking an old app like a 2.3 app all the way to a brand
00:21:35.640
shiny new 4.0 Russian dollar cache application so here are the main
00:21:42.120
the main points right you've got 2.3 3.031 and 4.
00:21:49.140
3 2 is if you're going to four you can skip three two
00:21:55.500
so what am I asking you to redo at each of these stages
00:22:01.440
if you're getting to 2.3 mostly it's about gems mostly it's about getting
00:22:08.340
your gem file in order it means looking at everything that you're requiring in your
00:22:14.880
2.3 or below application and making sure that that's specified in
00:22:19.919
your gem file with a version the version that works right most gem files that I
00:22:27.240
see don't have version info information stamped on them they're just uh will
00:22:32.460
page in it if you ever actually do a bundle update or if you were to try and extract out
00:22:39.659
and and do it it's very unlikely that when you run bundle
00:22:45.299
that's going to work you need the version or in most cases the branch that is rails 2.3 compatible
00:22:52.860
get that into your butt get that into your gem file and if you get that up and working
00:22:58.380
you have made significant progress 3.0 there's only three things that you
00:23:05.280
have to rewrite one is your router so if you in a rails 2.3 just have the
00:23:14.220
controller action ID specified you likely need to change that and come
00:23:20.159
up with a router that makes sense likely restful routing but something that makes sense that
00:23:26.460
accurately describes what is going on
00:23:32.880
asking you to rewrite your JavaScript so let's say that you have a 2.3 app
00:23:37.980
it's likely written with prototype right it's likely written link to function
00:23:43.679
linked to remote so we need to change those over to
00:23:49.440
unobtrusive JavaScript this is hard this is a big step
00:23:56.580
lastly you've got your queries that you have to change and by this I mean your active record interface right so this is
00:24:03.539
changing from find by with conditions to a series of Scopes and like
00:24:10.140
model.ware.ware.ware it will be easiest to do this
00:24:16.260
if you take your find buys and create
00:24:21.659
class methods that represent what that is bringing to the table so if you've got find all conditions published true
00:24:30.900
change that to post Dot find all conditions or find all
00:24:36.960
published right write that method have that change to the aerial interface
00:24:43.140
you do that change in rails 2.3 right get everything underneath your model
00:24:51.539
so you get that up and running it is seriously time to celebrate whatever if you get that into production
00:24:57.659
you're good to go at this point in time you're likely moving to Ruby 1.9 0.3
00:25:07.400
mostly there's not very many changes that you have to do with that
00:25:12.780
if you're doing some crazy threading stop
00:25:18.000
um but mostly you weren't doing that anyway in 187 right so now we move over to rails 3.1
00:25:26.340
here again asking you to just rewrite your CSS in your JavaScript why do I say rewrite at this point
00:25:32.940
it's more about organizing but in rails 2.3 it was very and even 3.0 it was very
00:25:40.140
common to have a series of JavaScript tags one per page that you would have
00:25:46.440
where it would only impact that page because you were only including it on that page
00:25:51.659
so it had free reign to change whatever page that it wanted it didn't have to play nicely with the other pages
00:25:58.080
that's what this is all about is bringing all of those CSS files into
00:26:03.179
into your app assets style sheet folder and then making sure that they play nicely with others
00:26:10.559
so if you were already using an asset packaging tool like jam it or one of the
00:26:16.080
others this is going to go easy for you but if you weren't and you have to look at your CSS file
00:26:22.620
and see which you're overwriting the others mostly this is a case of moving
00:26:29.100
all of your CSS files into app assets style sheets and looking at all your pages and seeing what doesn't look right
00:26:35.820
same goes with JavaScript whereby if they were overreaching and they were trying and they don't play nicely with
00:26:42.539
others so when you actually rewrite in 3.0 to
00:26:48.059
jQuery and obtrusive Style make sure that they play nicely have
00:26:53.340
that thinking when you rewrite that you should be more selective about what
00:26:59.520
you're attaching to decent way to do this is add a tag for
00:27:05.760
the controller to the body tag and then have your jQuery
00:27:12.299
when if it if it's attaching to events just on that page have it look at the
00:27:17.880
body tag with the data controller ID right or the action and have it only specify
00:27:25.740
items there that way when they're all put together later it'll all just work nicely
00:27:32.159
you get your rails 3.1 app online and users are happy do a jig you have earned
00:27:37.380
it this is a good thing in rails 4.0 I'm just asking you to um
00:27:43.260
basically go into your controllers and rewrite your forms this is implementing strong parameters
00:27:49.500
and then everything else is just a gem file update in rails 4.0
00:27:54.960
and if you get to rails 4.0 congratulations now you can start preparing for rails 4.1
00:28:02.340
so to recap rails 2.3 with bundler rails 3.0 with arrow 3.1 with the asset
00:28:10.140
pipeline 4.0 with gem file updates golden
00:28:17.100
there's some tips to getting to 3.0 let's say that you are heavily invested
00:28:24.240
in Prototype heavily invested not just in Prototype
00:28:29.760
the JavaScript library but in the entire idea
00:28:35.039
of the controller updating the page
00:28:40.860
there's a gem called prototype rails it was extracted from rails
00:28:46.740
in 3.0 and it will continue to work right now
00:28:55.860
can you if so if you don't want to rewrite or refactor your views you can
00:29:01.140
continue to use this this is pretty cool right this can this
00:29:06.179
can get you major instant wins by being able to upgrade with prototype
00:29:11.760
rails the downside is that prototype by itself
00:29:19.799
doesn't have a no conflict mode right it's it's just got the dollar sign so it wants the dollar sign
00:29:26.940
jQuery also wants the dollar sign right it's all about the money um
00:29:32.279
and so you can turn jQuery into no conflict mode you can have your code the
00:29:38.100
no conflict mode the trouble comes in when you use libraries that don't use no conflict
00:29:44.700
mode because then you get really weird JavaScript errors about like no selector
00:29:51.899
and path and stuff like that Twitter bootstrap
00:29:57.299
has in the past had this problem where the authors inside just use dollar
00:30:02.820
sign so you have to look at the code of the libraries that you're using and see if
00:30:09.179
they are writing it in a jQuery no conflict Style which they should you should edit it and
00:30:15.779
submit pull requests rails Auto Link this is used not as
00:30:22.679
frequently but it exists it is a thing and it will help you if you are big into
00:30:30.240
users submit content you want to link show a link for anything that they add you can use this
00:30:37.500
if you look if if you attended Brian's talk on
00:30:45.299
doing this you'll likely want to make sure that I can't have a link that has
00:30:51.600
JavaScript in it so you need to take a take a look at that but this will help with that
00:30:58.020
deprecated finders is good too so if you don't want to rewrite all of your fine buy with conditions you can
00:31:03.299
use this what is the lifetime of these though
00:31:08.460
you generally have one major rails version with these gems that have been with this code that has been extracted
00:31:15.419
out into gems before they're going to start breaking and no one's going to care
00:31:21.899
you can take advantage of these fork and maintain
00:31:27.899
but that's not really how like unless you love these and want to do that
00:31:33.299
that's not really how you want to be spending your time you want to add features right
00:31:39.120
so you can use this as a life vest and then begin to move away
00:31:44.220
for example if you have a 2.3 app you've upgraded it
00:31:49.320
to a 3.2 app but you didn't necessarily come up with a new user interface right
00:31:54.659
you didn't change it you use the Prototype rails to make sure that the link to
00:32:00.679
functions work and that the controller can send code because it's sort of
00:32:05.820
spaghetti in your you have in your mind that you're going to upgrade everything
00:32:11.299
at some point you need to upgrade that right at some point you need to get your
00:32:16.380
JavaScript house in order so this can help you but you can't depend on this long term
00:32:24.779
so we need to talk about Authentication in your 2.3 apps and uh in in your 1.0
00:32:31.919
apps your authentication was often access authenticatable
00:32:37.440
authentication module some code you found that you put in the lib directory
00:32:43.380
um that that hash passwords and and worked but we need to upgrade that
00:32:52.080
in that same talk Brian talked about how if you're using SSA sha as your password
00:33:00.000
that it can be hacked within a couple weeks using hobbyist Hardware a couple weeks doesn't sound
00:33:07.320
ominous but you shouldn't be able to do this it should take you something like the lifetime of the
00:33:14.100
universe plus a couple years to have like true password strength right and that's what bcrypt provides
00:33:20.820
so we need to upgrade your authentication systems
00:33:26.640
what does this mean well you don't know your user's passwords right right right
00:33:34.860
you can't get them back and so what you're going to have to do is go ahead and bite the bullet
00:33:41.460
install like devise or sorcery even auth logic right
00:33:48.179
you can install those get them set up and then you're going to have to email your users a
00:33:54.059
click here to reset or change your password your users are going to say that is
00:34:00.539
weird something is up I wish they're a way around this but there's not right there is something
00:34:07.559
up if you're not using decrypt your passwords are not as secure as they need
00:34:14.040
to be
00:34:19.139
not for fun stuff okay so what we need to do is we need to always be upgrading
00:34:24.419
right like there's that sales thing if you're always be closing
00:34:29.580
so what you need to be doing is you need to always be upgrading there is a percentage of time
00:34:34.800
of your day-to-day week-to-week year-to-year life that you should be spending upgrading applications
00:34:42.540
this does not mean maintaining apps but this means staying current on what
00:34:48.480
is changing right now dhh's additions to rails
00:34:56.220
tend to be gems that he writes for inclusion later
00:35:03.599
so this means that you can and probably should be installing on your 3.2 apps
00:35:10.440
even if it's a fake 3.2 application just install strong parameters and strong install cash digest and see what it's
00:35:17.640
like this is great to do at Ruby meetups right your local Ruby
00:35:24.240
Meetup and you're like hey who's got to talk who wants to talk about something just download and install and try to get
00:35:30.540
working one of these new apps that way when rails 4.0 comes out all you're
00:35:36.480
doing is saying oh yeah I know how to do strong parameters I know how to do Russian cat doll caching
00:35:42.420
you can take advantage of them before which will make future upgrades faster so whether that time is five percent of
00:35:49.920
your time looking at rails change logs that are coming through
00:35:56.339
whether that's a little bit more or a little bit less it should be something that you're constantly doing because
00:36:02.820
rails just changes so often and if you ignore the changes you get to the point where maybe some of you are at in your
00:36:10.800
organizations where you can't even use the newest gem
00:36:15.960
that you want to use because you're so far behind that is why
00:36:21.480
the 2.3 to 3.0 is starting to take place right I'm seeing more and more people
00:36:27.960
that are interested in upgrading from 2.3 to 3.0 over time
00:36:34.560
so there's this checklist of stuff that you have to do I mean I describe like big swaths of of stuff for
00:36:40.980
you to do upgrade your CSS but what you need is you need a little
00:36:46.800
checklist of everything that you need to do so I created one for you
00:36:53.160
and so you can go here this is launching like today rails upgrade checklist it's a completely free
00:36:59.820
list of everything that you need to do to get from 1.2 to 4.0
00:37:06.359
and it looks like this so the idea is that you have this list of things that you need to do
00:37:14.520
and if you follow it you'll probably get say 90 percent there
00:37:20.820
one of the cool things that you can do is if you look at the source code it's just markdown you can copy that and paste it into a
00:37:28.500
GitHub issue and it'll look like this and these are fully functioning
00:37:33.660
checkboxes so you can check them right wait check them
00:37:45.599
I would recommend that you would divide these up into issues right you would
00:37:50.760
divide get get to 2.3 that's an issue and check it as you go
00:37:56.160
get to 3.0 and you check it as you go right because you should be deploying and getting feedback on each
00:38:03.000
of these things if you tried to take a 1.0 app and get it to 4.0
00:38:11.040
without user feedback you could even be spending time on the on the completely wrong items
00:38:17.520
so you need to get to a point and then see where you're at get to a point and see where you're at it's like validate
00:38:23.160
it okay thanks my name is Jesse
00:38:52.740
thank you