you're not using yet and there is a URL you can follow along with the slides. About me, my name is Craig Buchek. I've been using Ruby since late 2005. I started with Rails like most of us. I've had occasional forays into other languages, which just makes me appreciate Ruby more. I am an independent contractor, always looking for new work. I specialize in Rails rescue projects and agile tech needs. And I'm also a sometimes contributor to this agile life podcast. So first I want to talk about what is an idiom. So the dictionary gives us a couple definitions and most people when they're talking about programming languages, they kind of concentrate on this first definition, something that can't be understood from the meaning of the separate words, but has a separate meaning of its own. I prefer this definition. I think this is closer to what we mean when we talk about idioms in programming languages in idiomatic Ruby, which is a form of expression characteristic to a group of people. So that's going to be my working definition, a way in which we normally express ourselves in Ruby. So here's some examples of non-idiomatic Ruby. I can tell that these were written by someone not very familiar with Ruby. Maybe they're writing Java in Ruby. So the first one uses a for loop. Idiomatic Ruby uses a for loop so little I had to look up the documentation just to figure out how to get that syntax right. You'll notice that the indentation is not the standard two space indentation that we typically use in Ruby. The second one is longer than it needs to be, but not just that, it takes more effort for me to understand what it means. So we've got the I equals and we've got the initializer for the dates and then we go through a while loop and we add things and then we have an explicit return at the end. So that's pretty non-idiomatic Ruby. So the idiomatic versions of this, we use a five times or we could use an each there instead of a for loop. And let's see. I can tell that the person who wrote this probably is at least a little familiar with Ruby. And the second one with the expiration dates is a lot clearer. And I actually ran into something like that second one in the past couple days. It happened to be JavaScript, but it was very non-idiomatic. So one of the things I struggle with, what's the difference between an idiom and a pattern? And it seems like people disagree, but a pattern is just a template for a common solution to a common problem. And this doesn't just mean design patterns and architectural level. There can be different levels of patterns. A great book is Kentback's Small Talk Best Practice Patterns. It talks about patterns at the method level and very small low-level patterns. So in this presentation, I'm going to treat the two terms somewhat interchangeably. So why do we use idioms? They're tools that Ruby gives us. Not necessarily on purpose, but they still are given to us by Ruby. And they're tools that Rubyists can help you with. And often Ruby is optimized to make idiomatic versions work better than the non-idiomatic versions. So surprisingly, that for loop might actually work less than the five times loop. So the first one I'm going to start out with memoization. It's pretty simple. Hopefully most of us have used this pretty often. Let's see. If the instance variable is set to something that's not falsely, then the instance variable will be returned. So if we've already set the at yesterday, then we'll just return that. Otherwise, we'll actually perform that computation, date today minus one. And this won't... Well, if your calculation might return false or no. So that's one caveat when you don't want to use that. But you use it to cache expensive operations. If you're going to take a lot of CPU time or if it's going to take some IO, if you're going to have to hit the disk, then you might want to consider memoization. But don't just use it without thinking. Sometimes you really do need to recalculate every time. And the example on that previous slide, if your process might run more than a day, you're going to end up with a bug. It's going to be really hard to track down because yesterday is going to be three days ago instead of one day ago. So think before you use memoization. So there is a gem for memoization. But for the basic case, it's not really worth bothering. There are some more difficult cases, like when you do care about nil, and if you have parameters. It turns out most of the times in Ruby, that's not the case though. I think it's because we extract objects better. So each object is implemented by itself, self-contained enough that you can just memorize without parameters. The next one's pretty simple. This one comes from OptiGrim, from his blog and from his Ruby Tapas episodes. This works best for hashes and arrays and hash like objects. So in this case, we've got a hash like object to get environment variables. And the typical way we do this is with just the or, sort of similar to the memoization. We check to see if Ruby version environment variable is nil, if we don't have it set. And if it's not, we set it to 2.1.4. The problem comes when if Ruby version could be nil or it could be false, that's going to still return the 2.1.4 even though that may be a valid value. So the alternative is to use fetch instead of the square brackets. If you use that without any block argument, it will raise an index error if it's not found. And it's helpful to ensure that you don't pass nil around. So if you have a nil and you keep passing around, you get a no method error at a later time and you don't know where that came from exactly. You'd have to trace back to figure out where it got set. The second version is the one that Opti recommends as the default. So you don't have to think about it. If you don't want to have to think about, do I have to worry about nil, do I have to worry about false? Prefer that version to the first. And an even better version if you really need an explicit version specified is just raise an exception in that block. It's good for failing fast and being very explicit about how to fix the problem. Alternatively, if you're the one creating the hash, you can actually new it up with a different default. In this case, we knew up the hash to return not found as a symbol if the key doesn't exist in the hash. So that's an alternative to worrying about nil and false. Note that array doesn't have this option. And ENV doesn't either because we don't ever new it up ourselves. The next one I want to talk about is tag module. This one also comes from Abdi Gurum. It's from his book called exceptional Ruby that talks a lot about exceptions. So a tag module is a mix-in module whose sole purpose is to add types to an object. Now, that sounds kind of weird because we don't use types during much in Ruby. Although if you watch the previous presentation in this room, sometimes we do. About the only place we use it is actually to test for types in an exception handler. And here's the implementation. So the idea is here that I've got my own library and I create my own error type in my library. And I do something and I rescue an error, but then I extend that error with my own type and then I re-raise that same error. So what this does is allows the caller to rescue either my lib error so he can get any errors that come from my library, or he can also rescue on the original exception. Plus, he has all the information available from that original exception. So this next idiom, I actually ran across him when I was doing some Java work, but it works great for if you're using capybara and cucumber. So what we do for a page object is we use an object to represent a screen in our application. And this is mainly for full stack testing, acceptance testing. And within that object, we have methods that represent actions. And then we have different methods that represent things on the page that we might want to query. So this abstracts away those actions. You don't have to specify all the details. And that's one of the problems with Cucumber is all the steps end up being in these worlds, but there's just one big pile of methods that you can call. This gives some object orientation to your testing. So here's an example. So we create an instance variable called home page. We create a new login page object. That's our page object. And then we log in. We tell it to log in. And we just pass it username and password. In this case, I did something a little unusual. On the initialization, I actually visit the page. We may or may not do that depending on on your use cases. And then we've abstracted the details into this page object. So when I call login page dot login, I don't have to worry about all those details, like filling in the user if the username field ended up being called email instead of user, I could fix that in that login definition instead of every place I want to use it. And one of the advice that they give on using page objects is if you perform an action return another page object. So in this case, when I log in, I end up at the home page. And I create a new home page object based on that page and return it so I can later interact with that. So that's why I signed it to that as a very top to the home page instance variable. Another idiom that we use in tests, there's quite a few idioms we used in testing, especially if you're using RSpec. So one of my problems that I've always had is mocking. So mocking is where you set an expectation for what's going to happen before you actually run your code. And I'll show you an example here shortly. But the problem I've always had with it is it doesn't fit the pattern. So there's three ways of expressing the patterns that we normally use when writing a test. The X unit standard terminology is set up exercise verify teardown. The one I like to use is arrange act assert. And then the more modern version is given when and then. So in the first example, the down at the lower part invitation dot deliver is our act. And the expect invitation to receive deliver is actually making an assertion, but it's making it in the wrong place. And that makes it difficult to to move the the act part into a common section and it and the setup into a common section. So RSpec three and I believe 214 actually gives us a different way to do it. We can actually do expect invitation to have received. So we get to make that verification that assertion after we've actually done our actions. So the tricky part there is that we actually have to set up our test double up at the top. But we don't really have to set up that verification until the end. And this way we can move up the we can move that invitation delivered to a before block if we want. And the assertion only runs in one place in that case. So the next one I'll talk about is allow class or instance. So I came across this in one case. I don't know if it's generally applicable, but I did find one use for it. And I'll show you that now. So this is I was actually writing a date class for the crystal standard library. So crystal is kind of what Mott's talked about earlier today. It's a language that already exists and it is mostly Ruby. It is compiled and it does type inference. So it's a new language and I was creating a date class for it. And one of the tricky things about date classes is the U.S. changed its calendar in 1752. And we changed from the Julian calendar to the Gregorian calendar. So if you're on a unique system you type Cal 1752 space nine. It will actually print a calendar that is missing 11 days. And so if you want to get your date class right you have to make that work right. So in this case I wanted my default calendar to be a combination of the Julian calendar and the Gregorian calendar that changes on a specific date. So I've got a Julian class and I've got a Gregorian class. And then I've got a third class that basically combines those two. So the trick was when I'm creating new and up a date sometimes I don't want to provide what calendar I'm using. I just wanted to take the default. Sometimes I want to say this is the Julian calendar. Sometimes I want to say this is the Gregorian calendar. And sometimes I want to say well I'm not in the U.S. and in fact that those two calendars didn't change in 1752. Every state every country actually changed on a different date. So sometimes I need to be specific about when this calendar changed happened. And so the implementation actually ended up being pretty simple. Basically I say if the calendar is a class, new it up. Otherwise assume it's already been new it up and it's an instance. So there were some alternatives I considered here. I could have made Julian and Gregorian into constants instead of classes but then I'd have to give them singleton methods and that didn't seem like a good answer either. So this seemed like a sort of a new idiom that I hadn't come across yet before. The next one is configuration query and co-worker of mine came up with this. So normally when you're grabbing some configuration data, you'll ask the configuration file what it looks like. We decided to take that up a level instead of asking what does it look like. We want to ask more of the actual question we want it answered. And in this instance we were doing some extra logging and we want to say hey does this applicant get extra logging. So we just made the API that one level higher. So we got to use a couple other idioms in our implementation of this. One is defining a class method with self there on the second line self for applicant. And that's our main API. And in fact we probably would have made the rest of them private if you could make class methods private here. So we're using some memoization in that second method there. And the third method is loading a file in parsing. So that's something that's going to take some CPU time and some IO time. And one of the nice little tricks we were able to do with memoization is we actually used unmemoization in the reload. So when we got a signal we call this reload method. We set those memoized instance variables back to nil. And so the next time it comes through it actually refetches the data. So that was a nice little idiom that we came up with. So the next one is the one that sort of instigated this whole presentation. And for a long time when I started using Rails we come up with we've got these different orms or different libraries. And you've got you know your model class and you include the orm. And then you provide a separate line that configures that orm. And that always bothers me because I always thought well isn't table more like an option to that module being included? Couldn't we just put it up there? And so of course I tried you know let's see if we can write something like that. And I tried adding table colon people to the include. But that's not Valley Ruby. Include can take more than one argument but they all have to be modules. So for a long time I'd look for a solution and didn't come up with one and had assumed that there wasn't one. And then I was reading some source code for Vertis or actually just the documentation for Vertis and it told me how to use Vertis to create a model. And I found what I've been looking for for several years. And so the next thing was well how the heck is that working? What is that doing? So we've got Vertis.model and then parentheses so that's just doing a function call right? Or a method call. And it must be returning a module because that's all that a include statement will take. So what it's doing is it's using the factory pattern to create a module and it configures that module dynamically per the parameters that we pass it. So I've got an example here of a simple implementation of how this can work. And again we're using a few simpler Ruby idioms here. We're defining class method. We're modifying an object in line with tap there. That's pretty common in idiomatic Ruby. We're using the fetch with default value from obd there. And we're using an options hash which is pretty common to pass in arguments. And one of the tricks here is that we're actually accessing a private method there was send. So we're taking that module that we created with module new and we're passing that to tap and called it mod. We can't call it module because that's actually a keyword in Ruby. And so we're sending include to that module or to that module to add the model constructors. So we're creating a module that's getting other modules included to be included into our model. So we can do a lot of different things with this. We could actually take positional parameters. We could take a block. We could use the builder pattern. Anything that ends up creating a module can be used in that include statement. And as my friend Amos wants me to point out the vertus.model there doesn't have to be a lowercase. You can actually use an uppercase model there. You can have methods with uppercase names. Let's see. So this is kind of I'm kind of one of the first people to discover this at least in the wild. So I wasn't able to find a name for this pattern or idioms. So at first I call it parameterized module inclusion. But then I realized it's just a factory building module. So I decided to call it the module factory. The next pattern I'll talk about is circuit breaker. And this came to me by way of Martin Fowler who wrote patterns of enterprise application architecture. And he says you got it from Michael Nygaard from release it. And this comes from Martin Fowler's Blicky. And so this is trying to stop an avalanche of inaccessible resources. So sometimes when you've got a slow resource a slow server and its API isn't providing you any answers. It's timing out. It's down or whatever. Sometimes that will cause everything else to fail. The idea of the circuit breaker is hey let's stop the failure. Let's stop the bleeding right here at its source and respond to it in a better way. So that might be a slower or unresponsive network resource. You might have filled up a queue. You might have a thread pool or a connection pool that's been exhausted. And you need to somehow deal with that in a same way. This is a little harder to explain in a very short amount of code. I will point out that there is a circuit breaker gem that you might want to take a look into. It's by W. S. Argent on GitHub. And there's also an article on Martin Fowler's Blicky. So the idea here is when we're trying to do something before we do it we see if the circuit's already been broken. And if it's already been broken then we don't want to make that call. Or we might actually want to make that call maybe one times out of 10 and just see if it's up. But we don't want to make it every time for sure. And then if there's a problem we rescue that error. We break the circuit anytime there is that error whether that's a time out or some other not their error. And we probably want to re-raise that exception. And so the other code is just basically seeing if the circuit's already been broken and some simple code to break the circuit and a way to reset the circuit. Now in this case there's no automated way to reset the circuit and that may actually be your case. You may send some logging and alerting for someone to manually reset the circuit. Or you may find some way to to reset that circuit. And like I said you might want to when the circuit is broken might want to try one out of 10 times and if it comes up three times in a row then assume it's up and you reset that circuit. So the circuit breaker pattern has a lot of different options. What do you do when it's broken? Do you just drop the request? Do you raise an exception? Do you use some sort of promise to return a value later? Lots of different things you can do depending on what you're trying to accomplish. Also the conditions for deciding when to flip the breaker. Do you do it on the first error? Do you wait for five in a row? Do you wait for 50% over a given amount of time? What conditions would automatically reset that circuit? You definitely want logging and alerting. If you're going to trip a circuit you want to have a log of what as much as you can what went wrong and you want to let someone know as soon as possible. And the next idiom I want to talk about is blue-green deployment. This is a deployment pattern and I'd like to see more Rubyist adopting this as a lot of us have done continuous deployment, sort of this continuum of testing, continuous integration, continuous deployment. I think the next one on that line is blue-green deployment. And the idea here is to have two complete production environments that are equivalent except for the code running on them. One is live and the other one is either the previous code or the next code. And when you're deploying you deploy to the one that's not live. And the other one just keeps running as it was. And you smoke test what you just deployed to and then you just swap the live one with the next one. So that's usually your load balancer pointing to the green and then moving to the blue or moving from the blue to the green. This makes it very easy to switch back to the previous deployment. We ran into a problem a couple of weeks ago where we deployed the wrong version and it took almost eight hours to restore everything back to the way it was. Had we had had a blue and green deployment we probably would have been back in about five seconds. So the trickiest part about this though is database integrity. If you started using the new database with the new code, do you lose all that data and go back to the old database? That's the hardest part about studying all this up. Do you make the database? Do you sync the two databases? Do you break them when you break them when you sync them? That's the hardest part about that. So the takeaway here is we should learn the idioms because there are tools that can help us to write better code. They can help us write more readable code and even more importantly it turns out that idioms are not static. We might find new ones. We might be looking for them and not find them for years and then all of a sudden we find a new idiom. And these new idioms, sometimes they fit with our existing idioms and extend what we can do with Ruby. So I've got some ideas for further investigation. These are basically ones that I didn't have anything important to say or I didn't have time to research and find anything interesting to say. Config blocks is pretty one of the popular things that we use in a lot of areas in Ruby. DSL is something we use in Ruby probably more than any other language. I saw a mention of flip-flops the other day. I've only seen mention of that twice but every time I see it it blows my mind. I saw a case where sometimes a method will take a block or a value which is pretty handy. In fact I think the hash fetch probably is using that idiom. Enumerable is pretty awesome. If you've got a collection always try to implement the enumerable module. Enumerator is related to that and I've not looked into it very much but it's sort of sort of gives you a sort of a promise or a continuation on enumerable return values. We can always use more object-oriented programming and object-oriented design in our Ruby. We could always use more refactoring. Keyword arguments is new to Ruby I believe 2.0 but refined in 2.1 and 2.2 is going to be coming out soon. So there's probably some ways we can use keyword arguments that aren't immediately obvious. Apparently we're going to have to learn about soft typing and how to use that pretty soon. And so other languages a lot of times some of these things I found in other languages that I found more applicable to Ruby than their original language. So always be on the lookout for new ideas that we can use in our favorite language. So a couple of the resources I used to find some of these Confident Ruby by Abdi Grimm and Exceptional Ruby by Abdi Grimm are where I grabbed a couple of these and Anything by Abdi Grimm. In fact Anything by Kent Beck or Martin Fowler would be great to read. Martin Fowler's Small Talk Best Practice Patterns is a great book on patterns in the small probably more close to what most people think of as idioms. If you think it's a little weird to recommend a small talk book at a Ruby conference Avi Bryant had a great talk at RailsConf I think it was 2007 maybe 2006. He talked about small talk in Ruby and how they're basically brothers twins separated at birth. So most of the things in that book are applicable. And Martin Fowler's books in Blicky. His Blicky covers pretty much all the patterns that his books cover sometimes in more depth and sometimes in less. And here's where I got the ideas for most of these. A memoization was suggested to me by James or Edward Gray. If you're have a question for a you want to talk to one of the people that are high up high up in the Ruby chain, send him an email. James actually answered my email really quickly and unbelievably thoroughly. So the page object idea came from selenium developers. It happened to be actually more for root for Java but it worked really well for Ruby. The config query was Kyle Stephens and myself a coworker of mine. And the module factory like I said came from Vertis. And if you're interested in the slideshow software, it's a slideshow called remark. And it lets me have show notes that I can see, percenter notes that I can see that you can't. It has a timer. It's really easy to use. Basically, you just have a template and you throw in some markdown and it does everything for you. And I would appreciate any feedback. My Twitter is Craig Buchek. GitHub is Buch. And email is Buchek.com. Thanks. I appreciate your time.


Welcome to video 9 of this series on the theory of relativity. Here we're going to examine a brief 1905 paper by Einstein having a title in the form of a question. Does the inertia of a body depend upon its energy content? Einstein presented a thought experiment that argued the answer is yes. Mass is a measure of the energy content of a body, expressed in arguably the most famous equation of physics, E equals MC squared. Here are the key points of his argument. One, energy is conserved. Two, a moving body has kinetic energy K that depends on its mass M and velocity V. From there follows three. If kinetic energy changes and velocity does not change, then mass must change. Four, the energy of a light pulse, a photon, is proportional to its frequency. And five, a light pulse has different frequencies, hence different energies for different moving observers, the so-called Doppler effect. The idea of kinetic energy is illustrated by our experience of lifting an object above the ground and letting it fall. An object on the ground has weight due to its mass M and Earth's gravity. To lift at a height H, we need to do work, that is, exert some energy W, which is the object's weight, MG, times the height H. Letting it drop, we find that when it returns to the ground, it has a speed U, such that the kinetic energy of one half M times U squared is equal to the energy we exerted to lift the object. And in general, kinetic energy should depend only on the mass and velocity and should be proportional to mass. Because, for example, lifting two identical objects requires twice the work and will produce, hence, twice the kinetic energy. A pulse of light clearly carries energy as evidenced by solar cells. In its 1905 special relativity paper, Einstein showed that the energy of a light pulse depends on its frequency. Indeed, this is a foundational principle of quantum mechanics where we say that a photon carries energy E, which is a constant H, times its frequency F. Now we consider the Doppler shift phenomenon. We start with the classical version. A particle at rest in a particular frame emits light waves of a given frequency. Two observers are on either side of the particle in a frame that moves to the right with velocity V. In a given time interval, the approaching observer passes through more oscillations of the wave than the receding observer. More oscillations per time means a higher frequency. More specifically, the particle has mass M and emits two photons of frequency F0, one to the left and one to the right. A frame that moves to the right with velocity V carries two observers. As throughout this series, we use units in which the speed of light is one light second per second, so V represents the velocity as a fraction of the speed of light. The observers are positioned so that one approaches the source while the other recedes. The classical Doppler effect predicts that the approaching observer will see the frequency increased by a factor of 1 plus V, while the receding observer will see it decreased by a factor of 1 minus V. Accordingly, the observers will see the photon energies increased or decreased by the same factors. Now let E represent the energy of the particle in the rest frame and H the energy of the particle in the moving frame. The subscript 0 will denote energies before the photons are emitted. The difference of the moving and rest frame energies is just the kinetic energy of the particle due to its velocity V relative to the observers. The subscript 1 will denote energies after the photons are emitted. Again, the difference is the kinetic energy of the particle. Now, the difference of the before and after energies in the rest frame is simply the energy carried away by the two photons, 2HF0. Likewise, in the moving frame, there we have HF0 times 1 minus V plus 1 plus V. The plus and minus V's cancel and the resulting total photon energy is the same as in the rest frame, 2HF0. The difference in the before and after kinetic energies is the difference in photon energies in the two frames, which is 0. So there's no change in kinetic energy. Since there's no change in velocity, there is therefore no change in mass. That's the classical result. Now we'll look at the prediction of relativity. As in videos 1 and 2, we'll use Latin letters for the rest frame and Greek letters for the moving frame. The particle is at x equals 0 and the observers are at xi equals plus and minus 1. The picture relativity paints in the rest frame looks identical to the classical case. The subtle difference is that as we've seen, the observers will have a different perception of time. Following the graphical approach we developed in use in videos 2 and 5, we draw a spacetime diagram. The particle is at x equals 0, the thick horizontal blue line. The receding observer is at xi equals 1, the top thick red line. And the approaching observer is at xi equals minus 1, the bottom thick red line. The tilt of the red lines is determined by the velocity v. In both systems, light moves with speed 1. Light emitted at t equals 0 travels towards the receding observer along the green line x equals t and towards the approaching observer along the green line x equals minus t. Light emitted one second later travels along x equals plus or minus t minus 1. Using these facts and the special relativity relations between the Latin and Greek coordinates, we can solve for the time interval between light signals perceived by the receding observer, call this delta tau 1, and likewise for the approaching observer, delta tau 2. We find that the frequencies, which are 1 over these time intervals, differ from the classical predictions. For the receding observer, 1 minus v is replaced by the square root of 1 minus v over 1 plus v. For the approaching observer, 1 plus v is replaced by the square root of 1 plus v over 1 minus v. Here we see the Doppler shifts predicted by classical theory and relativity. They agree well for low velocities, but at high velocities, relativity predicts more frequency increase for the approaching observer, the top curves, and less frequency decrease for the receding observer, the bottom curves. The change in light energy is due to the sum of the two Doppler shifts. In the classical theory, the sum is zero, but relativity predicts a positive sum that increases with velocity. That is, relativity predicts the moving observers will measure more emitted energy. More emitted energy leaves less energy behind in the form of kinetic energy. Since the velocity v doesn't change, that must mean the mass of the particle decreases. Let's see the details. Here are the Doppler shifts, the relativity values on the left and the classical values on the right. The squiggly lines indicate that they agree for small velocities. If we again look at the energy differences, the before and after energy difference in the moving frame is now hf0 times the sum of the square root factors. The Doppler shifts no longer cancel out, leaving a factor of 2. Instead, we find a factor of 2 divided by the square root of 1 minus v squared. That is, 2 times the dilation factor beta, the same factor responsible for the twin paradox. Relativity predicts the moving frame. We'll see the emitted light energy as a factor of beta larger than the rest frame season. The difference in the before and after kinetic energies will no longer be zero, but instead the expression shown here. Again, a change in kinetic energy with no change in velocity requires a change in mass. Now, notice the 2hf0 factor. That's simply the energy lost by the mass in its rest frame. We'll call that delta e. The decrease in kinetic energy is therefore delta e times the expression in parentheses. Now, Einstein points out that the expression reduces to 1 half v squared for small velocities, where we know classical physics works well. Here's a graph that shows the excellent agreement for small velocities. To make the connection with classical kinetic energy, we write the velocity v is the ratio of the velocity in meters per second. u to the speed of light in meters per second c. A classical kinetic energy is 1 half mass in kilograms times the velocity in meters per second squared. As we've argued, the change in kinetic energy must be due to a change in mass.  Canceling common factors and rearranging. We arrive at change in energy equals change in mass times the speed of light squared. Einstein's conclusion is the mass of a body is a measure of its energy content. If the energy changes by delta e, the mass changes in the same sense by delta e over the speed of light squared. Now, I think it's really important at this point to step back and remember what it is that makes a good scientific theory. Here's consummate physicist Richard Feynman describing the scientific method. In general, we look for new law by the following process. First, we guess it. Then we comp- Well, don't laugh. That's the really true. Then we compute the consequences of the guess to see what if this is right, if this law that we guessed is right, we see what it would imply. And then we compare those computation results to nature. Or we say compare to experiment or experience. Compare it directly with observations to see if it if it works. If it disagrees with experiment, it's wrong. In that simple statement is the key to science. It doesn't make a difference how beautiful your guess is. It doesn't make a difference how smart you are who made the guess or what his name is. If it disagrees with experiment, it's wrong. That's all there is to it. Yep. Everything we've described so far is really just a guess. An educated guess, but a guess, nonetheless. It's not a valid theory just because some guy named Einstein proposed it. I suppose that's why he titled the paper with a question. As he himself concludes, it is not impossible that with bodies whose energy content is variable to a high degree, the theory may be successfully put to the test. If the theory corresponds to the facts, radiation conveys a inertia between the emitting and absorbing bodies. Of course, one of the reasons Einstein is so famous is that he had a knack for making good guesses about radical ideas. Sure enough, 40 years later, delta E equals delta MC squared was demonstrated quite dramatically. A somewhat less intense test presented on the Centennial of Einstein's paper verified his prediction to a high level of precision. Now, how far can you take the change of mass into energy? Can you change all the mass into energy? Well, we now know the answer is yes, you can, as in the case of matter, antimatter, annihilation. So we are justified in simply writing E equals MC squared. Energy and mass are equivalent. The speed of light squared is huge, so we find that one kilogram of mass is equivalent to a huge amount of energy, about two and a half billion dollars worth if you could convert it to electrical power. If you use units in which the speed of light is one, as we generally do in this series, you get the very elegant result that energy simply equals mass. Back to our expression for the change in kinetic energy. This expression strongly suggests that the relativity formula for kinetic energy should be MC squared, the intrinsic energy of a mass m, times one over the square root of one minus V squared minus one, and that's just MC squared times the dilation factor beta minus one. And notice if V equals one, that is the speed of light, the square root is zero and one over zero is infinity. If you plot the relation between kinetic energy and velocity, you get the blue curve shown here. Newtonian theory predicts the red line. The two theories agree for small velocities, but Einstein predicts that as the kinetic energy of an object increases towards infinity, the speed approaches but never reaches the speed of light. No matter how much energy you exert trying, you will never get an object to reach the speed of light, let alone exceed it. The speed of light is an absolute speed limit. This is another radical prediction of relativity. Is it true? Well, a classic test was performed by Bertosi in 1964. He fired electrons at an aluminum plate. Measuring the time they took to travel a given distance, he determined the velocity, and measuring the temperature increase of the plate, he determined their kinetic energy. When he plotted his results, they agreed quite well with Einstein's predictions to within his experimental uncertainty. Indeed, every particle accelerator that has ever operated has provided overwhelming confirmation of Einstein's incredible predictions regarding the equivalence of mass and energy.