00:00:17.039
hello everyone i trust you've all had a very excellent
00:00:23.519
lunch because we are in new orleans the city of the most fattening lunch of all time i think how
00:00:30.240
many agree yes best most fattening lunches ever
00:00:36.480
so this is a talk i'm giving today the talk is about github flavored ruby and what i mean by that
00:00:41.920
is how we craft a system a methodology around the ruby code that
00:00:49.440
we write mainly libraries and i know this all sounds very fascinating but first i want to explain to you why
00:00:56.320
i'm wearing such a fine shirt because i know you're all wondering so
00:01:01.920
if you go to shop.github.com right now i believe and if not within
00:01:08.479
the next several minutes you all will be able to purchase this fine shirt for yourselves
00:01:14.560
and i know you're wondering but tom why is it pink the astute amongst you will observe that
00:01:20.720
today is october 1st marking the beginning of breast cancer
00:01:25.840
awareness month and you'll also see from the back of this fine shirt
00:01:34.479
that it is a very stylish homage to what we are at github trying to support
00:01:40.159
which is research into breast cancer where's my awareness month so in light of that all proceeds from
00:01:45.840
the sale of this shirt will go to benefit the susan g komen race for the cure
00:01:51.759
benefit for breast cancer research
00:02:00.960
thank you very much that's all no actually uh so let me introduce myself i am tom
00:02:07.759
preston werner this is my handle on github twitter everywhere else that you will ever find me on the internet
00:02:15.040
i of course work for and m cto of github and i already did that part check out
00:02:20.959
this high-res image that i totally just jacked from that page because i didn't have any internet a little thumbnail this is the future
00:02:27.360
people the future of internet is before you right now so today's talk is going to be around
00:02:34.400
these five technologies not really technologies approaches methodologies ways of making things more
00:02:41.040
awesome so the first relentless modularization the second readme driven development the third rake
00:02:47.840
gem the fourth tom dock and the fifth semantic versioning these together form the basis of a lot
00:02:55.519
of what we do at github when it comes to deciding how to code what to code and how to let other people know what
00:03:01.760
we're coding so let's talk about the first relentless modularization
00:03:09.519
perhaps you've seen some research online there is plenty this is this is a simple diagram of
00:03:17.040
two projects the one in blue is very small the one in large as you can see by its
00:03:23.200
name is very big now when we approach code bases when we
00:03:28.799
start coding projects start out small and they approach big shittiness over
00:03:33.840
time so how many of you have a small project and have noticed that these projects
00:03:39.360
are a pleasure to use they're a pleasure to write they're a pleasure to change they're a pleasure to integrate
00:03:44.879
with their pleasure in every kind of way when you work on on them they make you smile they make
00:03:49.920
you say ben yay perhaps i'll take myself down to cafe du
00:03:56.159
monde and beignet myself a pat on the back with four pounds of powdered sugar
00:04:03.280
so this is what we feel when we work on small code bases when we work on larger code bases
00:04:10.080
we get the spark to scream inside us and we want to kick people into giant bottomless pits and
00:04:16.560
why is that it's because these large systems these systems that grow over time large monolithic systems big
00:04:24.320
rails apps big things that we build for the enterprise for some reason the enterprise always has a lot of these
00:04:30.400
they end up this way and they end up this way because of the spaghetti codiness
00:04:38.479
the spaghetti codiness or the tangled slinkiness of these large systems leads us
00:04:45.360
to have a really hard time changing them it's what's called tight coupling type coupling is where all of your
00:04:51.600
systems belong to the same big system huge system when you want to go change one thing
00:04:57.840
you break a thousand others and it's because the code is all intermingled you don't know where one starts
00:05:03.199
and the other begins like this really up slinky so you're asking how do i modularize
00:05:10.639
how do i decide what to modulize or when to modularize something like when does something become so big
00:05:16.720
that something else needs to be extracted out of it as you're coding you should constantly ask yourself this
00:05:22.639
and every line of code that you write you should be wondering should this be modularized and i say
00:05:28.080
that the answer to this is everything should be modularized
00:05:34.400
all right i yell that because two weeks from now you're gonna remember this talk to be like hey
00:05:39.520
what did he say about modularization when should i oh right everything but time
00:05:45.680
heals all and so over time it will become less and you'd be like did he say modularized most things no you'll
00:05:50.880
remember everything and that is why the baby is yelling at
00:05:55.919
you to burn it into your minds
00:06:01.120
this slide left intentionally blank so at github at github let me tell you
00:06:08.400
about our modularization process it goes a little bit something like this we sat down in the beginning we said
00:06:13.440
let's build github and so we built github.com and then we said this thing is becoming big so what do we
00:06:19.280
do modularize so it started with grit which is a library for communicating from ruby
00:06:24.800
to git repositories on disk and then we said we need to be able to scale this thing
00:06:29.840
out so we built the smoke system which allows the front ends to talk to the back end and then we built burt rpc which is the
00:06:36.720
rpc mechanism by which those things communicate those of course go through proxy machine which
00:06:42.080
is establishes the connection between the front ends and the back ends that's routed by chimney because smoke
00:06:47.840
grit is smoke in the cloud obviously which is routed by chimney right
00:06:52.880
yeah no see it makes sense to me
00:06:58.639
uh behind that process is ernie which is a burt rpc server which runs the rest of grit on
00:07:04.240
the file server side when anything goes wrong that's handled by failbot gerv is when you ssh into a
00:07:09.680
system rescue is for handling jobs rockq is for putting jobs into rescue jekyll is for making pages that are
00:07:16.080
awesome node load is for handling downloads when you download things albino is for handling pigments and
00:07:22.080
giving you nice colored things markup is for turning all kinds of different formats into something that you can look at on a
00:07:27.520
page camo is for proxying non-ssl images into pages that are ssl and otherwise
00:07:32.960
would cause that little stupid-ass vlog thing and yeah gollum is for handling the wikis heaven
00:07:39.280
is so that we can deploy stratocaster handles all the events amen is for graphing haystack is reported to buy failbot our
00:07:47.039
exception logger hubot gives us a good time services are what you guys write to integrate with
00:07:52.560
services it's open source help.github.com is a separate modularized system so that you can learn
00:07:57.759
how all this crazy crap works and now what is the takeaway from this
00:08:03.120
how do you look at this and make any sense of it sure you say github congratulations you're really bad at naming things
00:08:10.639
but i think with the lesson comes from this guy mr rogers because mr rogers was if
00:08:17.280
nothing else extremely talented at make believe and that's the point of modularization
00:08:24.000
that is interesting the interesting thing about how we approach modularization at github is to say this
00:08:30.720
piece of code has become interesting enough on its own such that it could become an open source library
00:08:37.839
so anytime we sense that anytime we sense that any one of those components that we're working on is becoming
00:08:44.320
interesting enough to become an open source project then we will split it out and start treating it as an open source project
00:08:51.120
even if we have no intention of open sourcing that library we will build it as if it was an open
00:08:57.279
source project because that is how you decouple systems that is how you think in generalized terms so that you don't
00:09:04.080
build in all kinds of configuration variables and other little things that you do within your company
00:09:09.360
that makes sense to you but that make it hard to reuse your own technology in other places within your
00:09:14.959
company so always be thinking open source when you're modularizing things
00:09:20.000
it really prevents you from getting into that slinky situation because now all your pieces are
00:09:25.680
generalized and separated you can take that one step further and do what we really try to do
00:09:31.839
which is actually open source things and here's what you tell your boss when
00:09:37.200
he comes to you and you're trying to open source something say why would we open source this how is
00:09:42.720
this useful why would we do this what we do is open source anything that
00:09:48.160
is not a direct business secret type thing a a
00:09:55.360
so for us it's github.com that is the main that's the goodies right there getup.com is the goodies
00:10:01.279
everything else all the infrastructure all the other little open source tools that we build
00:10:06.480
those we open because they don't give us any strategic value it's infrastructure it's what we're
00:10:11.920
building upon just like we build upon linux and nginx and rails and all these
00:10:17.040
other things we want to give back to the community and we can do that safely because we
00:10:22.880
know that our competitors can take all of these things that we open source and use them but they can't compete with
00:10:29.279
us on the same level because they don't have that one thing that is the goodie which is github.com the rails app
00:10:35.680
so make that argument it's not a specific core business value item any kind of server
00:10:41.600
technology any kind of infrastructure tools for analyzing data all that stuff is really great to open source
00:10:47.360
because it gives you a lot of benefit in the open source community as well and helps you hire all of these things play together so we
00:10:54.320
try to open source as much as we can and i think everyone here and every company here should be doing the same
00:10:59.440
thing all right read me driven development
00:11:06.240
how many people have heard of read me driven development before okay wow that's amazing so i'll just
00:11:12.079
skip this section no instead i'm going to show you an awesome picture that i found on the
00:11:17.440
internet check it out there's like this big castle thing this is like some game of
00:11:23.120
thrones right here this is like a huge waterfall you know like niagara falls times a billion
00:11:31.839
i'm not just showing you this picture because i like describing it i'm showing it to you because of course it has a waterfall in it how many of you
00:11:39.680
despise the waterfall process deep down with waterfall and here's why
00:11:46.560
we despise it we despise it because i have it holy crap
00:11:51.760
see the fire this is the fire of evil it makes me trip on metal things
00:11:57.760
you can actually set a keynote transition to be as long as you want
00:12:03.360
this is the waterfall process it starts at requirements design implementation it's called waterfall because
00:12:08.720
each step must be completed before the next one may be begun and we hate it because it locks you into
00:12:15.600
making decisions and then never changing them before the funny thing about waterfall design
00:12:22.240
is that it was created sort of by chance or mishap by a guy named
00:12:28.320
winston royce in 1970 he wrote a book that explained this system
00:12:33.839
and then went on to say that you should never use this system he was using it as a counter example now
00:12:40.639
some people didn't read that far in the book and they said hey that's a fine way to design some stuff and they used it they're like
00:12:46.720
waterfalls awesome and then the government wrote specifications and baked it into their process and then we were all
00:12:52.639
doomed since then with overly big overly specified under awesome government types of things
00:13:02.639
and that is waterfall the big evil the thing that we as rails developers and ruby developers hate the most in the world so
00:13:10.639
to remedy that situation we invented cowboy coding
00:13:17.279
the thing about cowboy coding while it's extremely enjoyable as being a cowboy is
00:13:23.279
is that there's not really any rules to be followed there right we're all just on our own typing
00:13:30.240
away having a good time oh wait you want me to specify this first that's no i'm a cowboy i got my
00:13:35.680
last so i'm going to lasso me some code that doesn't make sense okay yes so
00:13:42.480
we went too far in the other direction though when you don't have any specification when you don't have anything to go
00:13:48.000
off of then you end up with code that is just a mess you don't know what you're doing you're re-implementing things you're wiping out
00:13:54.800
whole chunks of code and redoing it because you have to go back to the customer because you wrote it wrong in the first place
00:14:00.079
you never gathered any specifications at all and while that's fun it's not very productive and as i like
00:14:07.199
to say a perfect implementation of the wrong specification is useless and that's what happens in
00:14:13.680
either the waterfall case or the cowboy coding case
00:14:19.680
it's the wrong implementation and even if that code is the greatest
00:14:24.800
cleanest most amazing code that you've ever written at the end of the day if it doesn't
00:14:30.240
solve the problem that you intend to solve then it's useless so is there a middle
00:14:35.680
ground there must be some middle ground that we can do that gives us the best of both worlds some specification
00:14:42.480
but not too much specification and of course you already know the answer to this because it was in the title of this
00:14:48.959
part of the talk is that you write your readme first and that's really as easy as it is
00:14:54.160
you open up them or whatever crazy crap you're using
00:15:00.079
and you start writing you start writing the readme go find a readme that you like go find a readme that speaks to you
00:15:05.680
that is like wow this is a great readme it tells me everything i need to know to get started with this project
00:15:10.800
go find one of those and then for your next project that next project that you've decided to modularize
00:15:17.519
start writing the readme and write it in exactly the same way that you see it fully formed as if it was a fully formed
00:15:23.680
project so in your mind think ahead to when some user is going to be interacting with the
00:15:29.839
software and trying to figure out what it does at that point
00:15:35.279
you are thinking far enough ahead that you can make decisions good decisions about how the fully
00:15:41.920
formed project should be if you start coding right away you're going to discover as you're writing code
00:15:47.519
that you have to go back and change things all the time because that abstraction was wrong and that api method that you decided
00:15:53.440
would be great doesn't work at all or these methods are wrong if you write the readme and explain in code before you even write any code
00:16:00.639
just write it from an end user's perspective then you'll have something that will be delightful to use because you imagined
00:16:06.959
it being used before you even wrote it so this gets a little weird once you
00:16:12.160
have an empty project that is just a readme and someone goes to it they're like this project is amazing ah
00:16:17.600
crap so to solve that problem what i've started doing is writing the readme getting it to a
00:16:24.480
certain point that is kind of awesome and then renaming it to spec dot whatever format you're going to use
00:16:30.560
this now offers you a place that is what is what the readme is going to look like eventually hopefully
00:16:37.279
and as you begin writing and implementing parts of that readme you move those chunks of the readme
00:16:42.560
over or from the spec into the proper readme and that way when someone comes to your
00:16:47.920
project that is half implemented they see only the things in the readme the real readme
00:16:53.279
that are implemented they can start using it in its beta form without being really confused about what is and is not
00:16:58.320
available if you would like to learn more about this you can go to the googles
00:17:04.880
and just type in read me driven development you'll find my blog post probably is the first result otherwise
00:17:10.240
go down until you see tom.prestonward.comcrap and you can read a big thing that i
00:17:15.439
wrote about it explaining all of this stuff why i think it's awesome how i do it uh and why it's the right decision
00:17:21.919
so that is read me driven development and it's worked really well for me and a
00:17:27.439
lot of people that i've talked to say it's working for them so give it a shot if it doesn't work out
00:17:32.480
whatever but i think you'll like it the next step along this fantastic
00:17:39.440
journey is rake jam and rake gem of course is a plug-in i wrote for minecraft
00:17:45.280
that allows you to get rubies out of grass with a rake
00:17:52.080
so the way that that no i'm just kidding it's not that at all rake gem although that would be pretty
00:17:58.320
rad right you spend like a million hours down in those dungeons you guys find yourself when you're
00:18:03.760
playing minecraft ever you're down in like the dungeons and it's like three in the morning and you're just like oh my god diamonds
00:18:10.000
there's gonna be diamonds in here somewhere there's gotta be a diamond why do we do that what is it about us
00:18:17.520
that makes us just mine for hours for what oh god i had to give up minecraft it was
00:18:23.679
like totally anyway don't get involved with minecraft if you haven't it's it's like the end of
00:18:29.520
your life don't do it don't do it stay away okay so rig jim rig based
00:18:35.440
gem builder many of you probably use uh jeweler or hoe or some of the
00:18:41.600
bundler stuff or whatever to handle how you produce gems so you're sitting in your
00:18:48.000
project in your gem that you've decided to modularize on open source of course and start with your readme driven development approach you've got
00:18:55.120
some code and you want to share that with someone else via the amazing ruby gems ecosystem
00:19:01.280
so how do you do that you want to be able to get in there and use some rake tasks and that's what those systems are for
00:19:06.799
i've found some problems in the past with how those uh how those things mesh with my idea of
00:19:16.000
producing gems and shipping them and tagging them and all the things that i want to do
00:19:21.440
and the number one problem that i had with them is that i had to require them and when you had c extensions that you
00:19:26.799
needed to build and they wanted you to put the version number in some crazy place all of this stuff was really weird to me
00:19:32.559
and i said this stuff is not so complicated that it needs a totally external system
00:19:38.880
and so i wrote rake gem which is a collection of files that are really just templates
00:19:46.000
and there are no dependencies these are just templates that you copy into your own library when you begin it and you base your
00:19:52.799
future rake file and gem spec off of these two files that you will copy
00:19:58.480
so really what it is is a hand roll gem spec and a handful of rake tasks that allow
00:20:05.600
you to do the normal things you want to do things like deploying or rolling a gem building the gem pushing
00:20:11.600
it up to gem cutter running the tests creating the r dock
00:20:18.840
etc and so you get all of this with rage gem without having to require anything so let me let me run you through first
00:20:26.159
kind of what it looks like so you have an idea of it this is what the gem spec looks like if you go to the rick gem library and on my
00:20:32.720
github and look at it this is the gem spec so it it has a lot of exposition
00:20:38.159
that explains all of the different things in a gem spec and what they do kind of holds your hand through that process you read the comments and then
00:20:45.520
you fill in the values programmatically just you're just crafting a nice gem spec the way the gem specs were meant to be and gem
00:20:52.080
specs are really a pretty great approach to this they're very simple it's a very simple specification language
00:20:57.600
and it's exactly what i want to do in order to specify those things about my gem that are necessary to do this process so
00:21:04.480
let's use that it already exists and it's great so you go through here and you put in your summary and your description and
00:21:10.480
your author's email etc etc all the way down and that will now be the basis of your
00:21:18.080
gem tells it how to create a gem out of it along with that you get a rake file template that you copy into
00:21:24.960
your project and it looks like this the top of it is mostly just put yanking names out of things like finding out
00:21:30.960
what the name of the thing is via the file name of the gem spec little things like that like how to how to get the
00:21:36.240
version like where the version is and rake jem says i think you're going to put your version as a constant
00:21:41.919
in your top level thing dot rb if your gem is called thing then
00:21:47.360
you've got the thing rb in the lib directory et cetera it's that's where it finds it this is all explained in the readme for
00:21:53.360
this project so you get this template and because of that you get all of these rake tasks
00:21:59.360
that are just that come along for the ride these are what is contained in rick gem all the things that you are that you're used to doing with your
00:22:06.080
other packaging systems uh but the really nice thing about this
00:22:11.200
the thing and the reason that i wrote it is that rich m is infinitely customizable
00:22:17.200
more customizable than anything you could possibly imagine because it's just code in your repository customizing it
00:22:23.039
is really going into your rake file or your gem spec and changing something there's a whole
00:22:28.159
section of the rake file that says put your customized tasks here it's designed for that
00:22:34.480
here is a little bit lower in that rake file you see some tasks related to uh releasing so here's the release task
00:22:41.679
on the top and the way that i release is i go to i want to make sure i'm on the master branch so we'll test for that
00:22:47.600
i'm using get maybe using something different that's fine guess what go in there and change that command to be whatever you're running and then i commit it
00:22:54.559
and i allow empty ones in case i want to uh i have a pre-built message that's going to happen
00:23:00.159
i tag it with v something because i like v something but if you don't like v something for your tag names if your releases then remove the v or change it
00:23:07.120
to like a q i don't care doesn't matter because it's just code in your thing
00:23:13.679
right you can just change it however you want yes you get it okay so this is where you go to find this project read the readme
00:23:20.640
it'll describe all this stuff and give it a shot on your next project i think you really like it
00:23:26.240
it is it's really changed the way that i approach this because now instead of worrying about find digging up the documentation for
00:23:33.440
one of these other projects how to override something uh in ho you used to have to explicitly
00:23:38.480
remove it from the dependency chain because it would like include itself because there were no dependency um
00:23:44.559
there were no developer dependencies but now we have that you don't have to do that anymore
00:23:49.600
there's just shenanigans that you're going to want to do this allows you to do it so that is rape gem
00:23:59.120
so next up is tom dock tom dock is a project that i've essentially been
00:24:05.600
developing for about five years at first it was really just
00:24:11.600
a modification of simple rdoc format i looked at rdoc and i said hey
00:24:18.000
this is how people document their ruby code i would like to also document my ruby code so i will use
00:24:24.400
this system but rndoc doesn't really tell you much about how you should document your things or what
00:24:31.120
the what the approach is like should you describe things like how do i document variables uh or parameters and things like that
00:24:37.840
specify types so this is where timedoc came from i started just writing ardoc in such a way
00:24:44.159
that made sense to my mind and it didn't really eventually it drifted apart from
00:24:49.440
standard rdoc type of formatting and went into something else
00:24:55.039
and before i talk about specifically the formatting of tom dock i want to talk about at which level of documentation
00:25:02.640
tom doc exists i think there's four levels of code documentation those are line code that would be
00:25:08.720
something within a method where you describe a tricky section that's maybe doing some kind of crazy looping or
00:25:14.000
calling out to some external system and doing some weird parsing that you don't understand by just reading the code you want to know why that thing is happening
00:25:20.400
you put some line comments in there above each line of code and then you're fine code documentation
00:25:27.919
that's going to be at the level of methods and classes so this is the this is where tom doc is
00:25:34.799
going to stand this is this is describing methods as a whole more of your api
00:25:42.240
this is where our dock and yard and all of them sit that's code level documentation
00:25:47.600
next up that chain is api documentation that's a little bit similar to code documentation
00:25:52.799
except that it's aimed at a different audience the audience of code documentation is developers in the code the audience
00:26:01.440
of api level documentation are end users who are on the internet looking for documentation on how to use
00:26:08.159
and consume your library they don't care about the code that's in your library they only
00:26:13.440
want to know how to use your code in their libraries so api consumers and then above that we
00:26:20.960
have book level documentation which is long-form very expositional hand-holding type of
00:26:27.520
documentation like a book on rails as i said tom dock is code documentation
00:26:34.640
so why do we want to document code what's in it what's in it for us why would we spend the time to do this
00:26:41.279
these are the questions that i ask myself when i'm writing code these are the things that i want to know
00:26:48.159
we've got well what does that code do like what even does it do from a high level
00:26:53.200
what does this method do is it part of the public api should i feel comfortable using this method in my
00:26:59.919
code and assume that it won't change unless you tell me that what are the parameters that you expect
00:27:05.679
me to give you what types are those parameters and ruby we're all duct typed and so the the
00:27:11.360
parameter type that you want to give someone is unknown you have to dig into the code if there's no documentation to find that
00:27:17.200
out so just tell me that's what i want to know what are the valid options in rails we oftentimes have
00:27:23.039
long chains or very complex option hashes that we can pass down through a whole stack of methods i want
00:27:30.159
to know every single option that i can provide and what that option does how do i use
00:27:36.000
the damn thing how give me an example i would love to look at an example it's all i want in my life as an example
00:27:41.440
of how i use this very complex chunk of code and then what type of thing does this return what
00:27:47.520
ruby type does it return that would be extremely useful to know or to know that it doesn't return anything that i should care about
00:27:55.760
but more important than all of these things is the real reason that i want documentation and that is so that
00:28:02.799
my future self is protected from my past self and this is my past self check out that
00:28:10.399
shirt look i love ketchup all right i'm not
00:28:17.279
ashamed to say that i love ketchup okay and neither should you
00:28:22.480
this is my past self and the reason that i can still work on the gems and all the open source that i do today is because this guy
00:28:30.720
this guy was looking out for me he was looking out for future tom saying
00:28:36.320
hey future tom i'm going to document this method for you so that five years from now when you come back and you need to modify this
00:28:42.000
method you don't have to spend a half an hour reading the code you can very simply understand
00:28:47.360
that whole chain of thought by just reading these few lines so that is the real reason
00:28:54.240
that i want documentation future protection from past self
00:28:59.520
so let's look at it let's look at tomdak in detail what does it look like so here's a method it's called exist
00:29:05.679
question mark this is in gollum gollum is totally tom docked if you want to check it out that's a good place to do it and
00:29:13.760
i say okay uh well what does it do i have no idea there's really nothing here i mean i
00:29:19.120
can't see the code i'm sure it's simple but what is exist what kind of existence does that mean now once i document this thing i answer
00:29:26.240
a lot of questions i can say what does it do well it checks whether wiki's git repo exists on the file system
00:29:31.679
oh okay it's pretty straightforward is it public oh yes it is because it says public colon in the beginning
00:29:39.120
what type is returned well oh it returns a boolean true if it exists if all of it does not
00:29:44.720
so it's starting to answer some of these questions that we really care about here's another one this method is called write page
00:29:50.880
takes four parameters name format data commit those could be anything if i'm just looking at the code this is gonna take me a while to figure
00:29:57.200
out what each one of those is and what each one of those does so i write a little bit of documentation
00:30:03.600
and this honestly doesn't take that long to write it's pretty quick to write but it's going to save you zillions of hours in the future so now i can answer
00:30:10.559
some other questions such as what parameters are expected well i've got a nice list here
00:30:15.679
name format data commit commit is a bunch of options it's an option hash i can go in there and i can see very
00:30:22.080
easily what all of those things are and then what are the so what are the valid options these questions are asked
00:30:28.480
by spending about 30 seconds reading that piece of comment another one is how do i use the damn
00:30:35.600
thing cname that could mean anything self.c name right class method called cname
00:30:42.000
even with just a description it might be confusing if i just say convert a human name into a canonical page name well maybe that description could be
00:30:47.919
better without an example you're really confused about what that means if you don't already know what a canonical page name is
00:30:54.640
so here i show an example and i say oh well you take a human readable page name like you're going to see on a wiki page
00:31:00.640
and you want to convert it into something that you would put inside the url and so this says oh it's good it looks
00:31:05.919
like it's going to do some changes to make this thing usable on a url by replacing spaces and maybe other special characters
00:31:12.880
with dashes so now you know exactly how to call it exactly what kind of thing is expected
00:31:17.919
and what you should expect as a result so the whole specification is up online
00:31:24.960
uh this is what it looks like it's just it's very simple it's written in a very basic spec format
00:31:30.880
and it expounds upon all the details about how you should use it but please remember that tom doc is not a
00:31:36.480
rigid specification i mean when you read it you'll say oh this is a very rigid specification but more than that
00:31:41.840
tom doc is a lifestyle a lifestyle of just documenting stuff and not having to
00:31:48.320
remember or make decisions about what the format of that should be or what it should look like
00:31:53.840
just i want some documentation these are the ways that i think it looks really great and works really great
00:31:59.600
but at the end of the day as long as you're producing documentation if you get a few little things wrong if
00:32:04.799
you don't indent correctly or you don't line up this dash or that dash that doesn't matter because all that matters is that you're communicating
00:32:11.039
what the code does to your future self or someone else
00:32:17.679
and there's one more thing there's one more thing on this and that thing is maybe you know this guy
00:32:24.000
and originally i was gonna use that picture but that was too weird so this guy i'm happy to announce that
00:32:31.120
rdoc 3.10 will natively support tom dock as a format syntax so now you no longer
00:32:38.399
have to even worry about well how is how am i going to produce output for this thing eric spent the time
00:32:44.000
to integrate tom dock parsing into rdoc and it will be available in the next major release
00:32:56.159
thank you i'm super excited about it i mean it's huge for me and eric is an inspiration to us all and
00:33:02.080
that's so awesome that he undertook that so thank you eric are you here eric a hand of applause for eric please
00:33:13.039
so this is what the default output is going to look like right now when you do it it's going to it's going to split things into public
00:33:18.640
internal and deprecated just like time doc wants it's going to understand what the parameters are and format them really
00:33:24.320
nicely you're going to get syntax highlighted examples it's going to link things properly
00:33:30.559
it's even going to understand nested option declarations like the way that tomdak wants you to do them all of this is
00:33:36.880
going to be supported in first class so you know you no longer have to worry about people looking at you funny when you're tom docking stuff
00:33:42.960
and then your rdoc output looks like crap very soon all of that shall be solved if you want to learn
00:33:48.240
more tomduck.org that's the specification
00:33:53.760
and lastly semantic versioning semantic versioning is not so much as something that i
00:34:00.960
invented but a repackaging and naming of something that already existed
00:34:06.799
there's a lot of power in that as an aside if you come across things in your daily life or at work
00:34:12.560
that are complex concepts sometimes all that's required in order to communicate it
00:34:17.599
those concepts those complex things is to give it a name and give it a lightweight specification
00:34:23.200
and i've been doing this for a couple of different things it's really powerful just sitting down and saying how do i
00:34:29.520
talk to someone about this complex concept without having to explain the whole thing so slap a name on it like
00:34:35.119
semantic versioning and then write it down in a document and clarify what you're saying basically a
00:34:40.240
giant definition and now you can talk about that thing and start finding better ways to do that same
00:34:46.159
thing or talking about the merits or demerits of that system so naming things that's
00:34:51.760
a little bonus little bonus takeaway naming things super powerful so semantic versioning why is this a
00:34:58.480
useful thing to want to do there's two things that happen if you don't have
00:35:03.680
a rigid and reliable way to tell people how your versions are changing from time
00:35:08.720
to time the first one is dependency hell and dependency or i'm sorry the system of getting into
00:35:15.440
trouble is dependency hell dependency hell is two things one of them is version lock
00:35:21.920
version lock is when you bind too specifically to a dependency so if i uh if i require
00:35:28.960
for my library rake if i want to require that and i say i need rake version 7.3.5
00:35:36.800
fine everything's cool for a while but what if a bunch of other libraries also declared that they need a specific
00:35:43.040
version of rake that's slightly different now when you need to have both of those systems included in one larger system
00:35:50.560
the two of them are going to be like nope nope nope now which one do you use because both of them are saying that they need a very
00:35:57.040
specific release and so in some package management systems and this was a big problem for
00:36:03.280
us at powerset where i used to work was that over specification this version
00:36:09.200
lock prevents you from even installing stuff so that's one side of dependency hell is
00:36:14.640
over specifying something so that different dependencies start fighting you can't even install two things at the
00:36:20.320
same time the opposite side of that is version promiscuity where you get sick of version lock and you're like screw it
00:36:26.400
i'll just require any of them any version of rake is fine forever and of course that's going to lead you
00:36:32.400
to the to a similar problem which is anytime anyone upgrades or requires an updated
00:36:38.000
rake you're just assuming that all of that's just going to work well that's going to cause problems too
00:36:44.720
so either way you've got problems and you're in dependency held so how do you solve this the first thing
00:36:52.000
that you need to do is declare something like a public api whatever that means whether it's just
00:36:57.040
documentation whether it's all of the methods that are public i use tomdak to specify this because in
00:37:03.440
tom duck you can say whether something's public or not so with the public api in place
00:37:11.119
now you can start talking about how your project changes over time and the name semantic
00:37:18.560
versioning means that the version numbers themselves should explain how that thing is changing over time
00:37:26.880
that's all that you should require those numbers should be meaningful these three numbers should tell you a
00:37:33.119
lot about what happened in that release by just looking at the number you don't even need to look at the code or anything
00:37:38.880
these numbers will tell you if you use semantic versioning what happened to that gem since the last release so there's three parts
00:37:45.839
the major the minor and the patch version the major version is always backwards
00:37:52.240
incompatible so if i up the major version that says something in the public api
00:37:57.520
changed in a way that it will no longer work with what you're using right now so this
00:38:03.839
is generally something like a big change we don't like to do these very often because it makes people sad
00:38:09.520
they have to go in they have to change code they have to read documentation all of those things that we as developers really don't want to have to
00:38:16.839
do the minor version is when it is upped and the major
00:38:22.800
version is not then that means that that change was backwards compatible in semantic versioning
00:38:27.839
you change the minor version you can upgrade to that no problem good to go so new functionality
00:38:34.240
additions to the public api would always be backwards compatible because it's not changing anything it's not breaking any
00:38:39.599
existing code big internal changes you might also want to have be a minor release
00:38:45.119
just to signify that a lot of things changed but again it's backwards compatible as an end user
00:38:50.960
mainly that's what you want to know is it backwards compatible and this may also contain some bug fixes you might
00:38:57.040
just roll up a bunch of stuff maybe an api edition and some bug changes all into the same release
00:39:02.480
that is a minor version bump and lastly we have the patch version
00:39:07.599
the patch version is always backwards compatible as well because it has to be and should only
00:39:12.800
contain bug fixes so if you have some documentation you say this method produces this
00:39:18.640
result but in reality the code doesn't do that and you want to release something that
00:39:24.720
uh that fixes that to bring it back in line with what you've specified previously then that would be considered a bug fix
00:39:30.079
and that would go as a patch release in order to take advantage of this we
00:39:36.240
have something great in bundler it's the what we call the pessimistic version constraint or
00:39:41.440
sometimes called the operator
00:39:46.640
i rather prefer the latter so the gem command you say jim the name of your gem
00:39:52.000
use the pessimistic version constraint operator and then you have a version and this is a little confusing how this
00:39:57.440
version works so it's very simple though what you have in this version is 2.4 2.4
00:40:02.960
so in this example this means 2.4 and any version up to but not including 3.0
00:40:10.560
so as an abstraction think of it this way drop that last number the four increment the last number on
00:40:17.440
the remaining thing up to three and then you can go up two but not include that number
00:40:23.040
so that's how it works and this is going to keep you really safe because in this case you want to say i require
00:40:28.720
at least version 2.0 2.4 that has some api methods that i need
00:40:33.839
probably maybe something maybe from 2.3 to 2.4 some new api method was added that you
00:40:39.040
require so you have to have 2.4 because you're using functionality in 2.4 and if you can try to use the lowest
00:40:46.000
number that is actually compatible with your software because that will reduce the amount of vendor lock that
00:40:51.680
you have so 2.4 all the way up to three
00:40:56.880
and now you know that any version 2.4 or higher up to but not including three is going to be compatible according to
00:41:03.040
semantic versioning that has to be compatible so now you can very easily upgrade that gem to the new 2.5 version
00:41:10.240
without having any worries and of course you should always check this and run your tests and things but if someone is telling you by the way
00:41:16.960
a version number changes how that works then you've reduced the amount of effort that it takes to upgrade
00:41:22.400
and you're ensuring that you don't end up in dependency hell if you don't do this
00:41:29.599
then this guy will come after you and salt your blood
00:41:36.480
i'm really good at accents in case you couldn't tell uh the reason that he's on the screen
00:41:42.240
here is because if you don't use something like semantic versioning then you may as well just label your versions version one
00:41:49.440
version two version three version four because you're not producing any additional information if
00:41:55.599
you don't follow a system like this then those three numbers those three pieces of that version are just like
00:42:01.119
digits in a sequence that have no meaning so you may as well use those pieces of the version number
00:42:06.800
for something useful if they're going to be there at all you can check that out
00:42:12.000
at simver.org so in summary to wrap this up is your system broken
00:42:19.440
down into small manageable pieces if it's not you might want to consider
00:42:24.720
more relentless model uh modularization are you wasting too much time
00:42:30.319
uh because of too much or too little planning are you two waterfall or are you too cowboy
00:42:35.520
read me driven development might be a nice middle ground are you fighting your gem spec or you're
00:42:40.800
working with it rake gems a way to have infinite customizability without a lot of dependency
00:42:47.040
distractions is your documentation aimed at the right audience i think tom dock really explains the
00:42:54.000
audience that you should be talking to and reduces the number of decisions you have to make when you're writing that documentation
00:43:02.079
and does your versioning system help you out or not semantic versioning solves a lot of
00:43:07.839
those problems that you get into otherwise thank you very much
00:43:53.839
you