Greetings and welcome to the Introduction to Astronomy. In this lesson, we will go through and talk about more of the more understanding motion and how things work and how orbits work, and in this case we're going to specifically talk about Isaac Newton and our understanding of gravity. And this was something that had been missing for a long time. We did not have that understanding of what gravity was. Even if you look at some of the early thoughts as to how the orbits worked, you had things orbiting around nothing. So we had epicycles and what was at the center of the epicycle was really nothing. There was nothing there. Now, if you didn't have an understanding of gravity, that might make sense, but once you begin to understand gravity, we can see the big problems with those types of models. So let's look at what we know about gravity and some of the early ideas going back to Galileo's time. And Galileo gave us some of the ideas of motion. So we looked at Galileo before and we talked about his telescope, but Galileo also gave us some ideas on study of motion and gave us an idea of the concept of inertia. Inertia just means that things are reluctant to change their motion. And he also found that all objects fall at the same rate in a gravitational field. So it doesn't matter what two objects you drop. In a gravitational field, they will always fall at the same rate. It can be a hammer and a feather, as we'll see here in the Apollo 15 video. And this was done back in the 1970s by the Apollo 15 astronauts on the moon where they took a hammer and a feather and you'll watch the astronaut drop them and see that they fall at the same rate. So watch that they fall at the same rate, but also watch how slow they fall. If you can imagine dropping that hammer here on Earth, it would fall much faster. And that's because we're also seeing that the gravity is much less on the moon. So let's watch this video clip here. Here's a picture of a man and a 10-atometer drum in the ETB. I'll watch this. A good picture there. Beautiful picture, Dave. I guess one of the reasons we got here today was because of a gentleman named Galileo a long time ago who made a rather significant discovery about falling objects in gravity fields. And we thought that where would be a better place to confirm his findings on the moon. And so we thought we'd try it here for you. The feather happens to be appropriately a falcon feather for our falcon. And I'll drop the two of them here and hopefully they'll hit the ground at the same time. How about that? Mr. Galileo was correct in his findings. So hopefully what you noted there as you watch those two objects fall was not only did they fall at the same rate and that the hammer and the feather hit the ground at the same time but they also fell a lot slower because of the reduced gravitational field of the moon. So let's see what else we have here. And we want to look at a couple of definitions. We want to define a couple of things here in terms of two terms that we want to use and that we'll use at various times that are important for this. One is velocity and the other is acceleration. Now these are terms that you've heard of but we want to look at them here in a physical sense. And when we look at velocity and acceleration in a physical sense, they are vector quantities which means they not only have a magnitude, a size, so you might relate velocity to speed. Speed is how fast you are going but velocity has a direction associated with it. So your speed could be 50 miles per hour. That might be your speed but your velocity would be 50 miles per hour east. And it's very important that velocity has a specific direction associated. A velocity of 50 miles per hour east is different than a velocity of 50 miles per hour north. Yes, you're traveling at the same speed but your velocity is different. And acceleration is what happens when your velocity changes. Now we typically think of an acceleration as going faster and that is one example you can speed up. However, you can also have an acceleration when you slow down. We sometimes call this a deceleration here on Earth but in reality it is just another form of acceleration. Now one of the differences the other things that you can have is you can also have a changing direction is also an acceleration. So if you went from traveling 50 miles an hour east and turned to go 50 miles an hour north even though you went 50 miles an hour the entire time you were accelerating. Your speed wasn't changing but your direction was changing. Your changing direction can also give you an acceleration and we'll see that that means that there is a force needed here and when we look at that in terms of orbits that's what we'll understand as gravity. So let's look at what Newton, a little bit about what Newton gave us and here is Sir Isaac Newton and he gave us a number of different things. So what we're looking at here is his understanding of gravity but let's look at a few of the different things that he did. Not only did he give us universal law of gravitation and give us our first really good physical understanding of gravity that could then apply this to understand Kepler's laws so the laws that Kepler gave us for planetary motion can now be explained based on Newton's laws of gravitation. We'll also look at his three laws of motion. These are very general laws unlike Kepler's laws which applied very specifically to the planets orbiting the sun. Newton's three laws of motion apply anywhere and we know that Sir Isaac Newton also developed calculus to solve some of the problems of motion and gravity that he was working on. The mathematics was not sufficient and he needed something else to be able to solve that and he developed calculus as a way of being able to do that. So let's take a quick look at Newton's three laws of motion here and we'll start with his first law and Newton's first law of motion is what we call the law of inertia. So the law of inertia simply means and we'll state it here an object at rest or in a state of uniform motion continue in that motion unless acted upon by an outside force. What does that mean? That means that if you are moving you want to keep moving. If you are standing still you want to keep standing still and that applies to a person or any other object. An example of this could be riding in a car. When you are traveling down the road at a constant speed and you slam on your brakes the car comes to a stop but what happens to you? You end up lunging forward until something stops you whether it's the seat belt or an airbag or a steering wheel or the windshield something will eventually stop your motion. But why did you do that? Because you were moving forward you had inertia and you did not want to stop it as a property of all objects that if they are moving they want to continue in that motion. You can also look at the opposite point if you're stopped or if you're on a roller coaster perhaps one of the ones that starts and accelerates very quickly at first you feel yourself pushed back. Well, you were sitting still all of a sudden this roller coaster car starts moving forward and therefore you are pushed backward because you did not want to move until the roller coaster accelerates you up to that same speed. So that's an example of Newton's first law of motion that things at rest will remain in rest and objects in a state of uniform motion will continue unless there is an outside force acting on them. What that also means is that if an object is not at rest or in a state of uniform motion there must be a force that is acting on it. So there must be a force if it is not at rest or if it is not in a state of uniform straight line motion. So anything that is accelerating has to have a force acting on it and that can mean things speeding up, slowing down, or moving in a curve such as an orbit. So let's look at Newton's second law. Newton's second law tells us that f equals ma most concisely written as an equation here although what it also says in words if you want to write it out is that the acceleration of a body is proportional to and in the same direction as the net force acting upon it and inversely proportional to the mass of the object. What does that mean? Well it means that if you apply the same force to two objects the more massive one is going to be harder to move. That would be an example for if you have a car, a small car and it breaks down and you need to move it you can put it in neutral and one person can generally push it and move it off the road. You can get it moving and you're applying some amount of force to that it has a small mass. However if it's a fully loaded semi truck that breaks down and you want to push that with the same amount of force then what you have is you have the same force so this is the same this is larger you have a much larger mass and that means that the acceleration is going to be smaller and in fact you probably won't be able to even push with enough force to get that truck moving. With a car you'd have a much smaller mass even though you're still using the same force you're going to be able to then get a larger acceleration and get that smaller object moving whereas you could not move a larger object. So we can use this to say that if there is an acceleration if the velocity is changing and remember that velocity has a magnitude in a direction then there must be a force acting on that object. Now let's look at Newton's third law here Newton's third law tells us that for every action there is an equal and opposite reaction and for every force there is an equal and opposite force so that forces and action-reaction come in pairs. An example of this would be launching a rocket when you launch a rocket you are throwing material out in the exhaust downward and that causes the object to accelerate upward so material being pushed downward as one action and then the reaction is pushing this upward so continually doing that will launch the rocket upward into space. So those are Newton's three laws of motion that really explain how things move and they're applicable to anything moving in the universe they do not apply in just specifically talking about the orbits of the planets and they do not apply just to things here on Earth they apply everywhere. Now the other thing that Newton gave us was the universal law of gravitation let's read that out here and that says that the gravitational attraction of any two bodies is proportional to the product of their masses and inversely proportional to the square of their distance so Newton's law of gravity is shown here it depends as I said on the product of the two masses M1 and M2 you multiply those together you look at the distance between the two objects and divide it by the square of that and then there is a gravitational constant G that gives us the value of the force so for any two objects whether it be the Earth and the Moon or the Moon and the Sun you can then figure out the force between those as long as you can know the masses and the distance between them this is what we call a universal law it applies to any two objects in the universe that have mass and it is always an attractive force it is never something that is repulsive and we often put that in that the force is negative just to imply that it is always an attractive force you can never get to know two masses will ever repel each other if we look at other types of forces they can be attractive or repulsive gravitation is always an attractive force so let's look at an example here and we can look at some examples here what would happen if we were to do various things with the to change the masses now let's re-put up the Newton's gravitational it equals G M1 M2 over R squared so let's look at the first example what if we double the mass of one of the objects in that case we have we have G 2M1 M2 over R squared and the force is going to be two times greater if we double the mass of both objects we have G 2M1 2M2 over R squared and now we have that's going to be two times two is four times the increase in the force so the gravitational force will change very significantly let's clear this and look at our last two examples so if we increase the mass we increase the force if we were to decrease the mass we would have decreased the force so let's look if we triple the distance now the mass is the same so we have G M1 M2 but now we have 3R the quantity squared while 3 squared is nine so that means that the force is going to be nine times less and that is decreased because we have increased the distance between the objects and our last example here we can look at is we again G M1 M2 those don't change but now we're going to bring them four times closer together so it's now one fourth of R squared one fourth squared is one sixteenth and that's going to come to be 16 times greater we've brought the objects closer together so now it is going to be 16 times the force between them if nothing else has changed you could also change masses and radii together and get even a little bit more complicated values to try to work with so let's look at what Newton did what this did for Kepler's third law as we get towards the end here Newton was able to revise this Kepler gave us that P squared equals A cubed so the period squared is equal to the cube of the semi-major axis Newton revised this he actually gave us a slightly more complicated version of this but simplified it says that P squared equals the sum of the masses of the objects times A cubed this is very important because it allows us to determine the mass of objects if you know P and you know A you can then solve and then say that M1 plus M2 is equal to A cubed over P squared if you know the semi-major axis or the distance of the objects and you know how long it takes them to orbit you can then determine the mass of the central object this is something very important is how we can actually determine masses out there in the universe so let's finish up and summarize here and what we learned and looked at in this lesson we looked at a couple of things we looked at first of all all objects will fall at the same rate in a gravitational field the amount of mass does not matter it doesn't do that here on Earth because on Earth we have air resistance so there is a force that pushes things back up as you try to drop something light like a feather or piece of paper that does not occur on the moon Newton gave us the three laws of motion and we looked at those and he gave us the law of universal gravitation which eventually led to a modification of Kepler's third law which would allow us to determine the mass of objects in the universe so that concludes our summary of Newton and our understanding of gravity and we'll be back again next time for the next lesson so until then, have a great day everyone and I will see you in class


This is James P. Madonna of Megalife21. It happens to be Thursday, February 13th, 2014. I couldn't sleep. I woke up early. But the coffee dripping is not what this video is about. Because since we are having this mini ice age this year due to climate change, I will show you why I'm taking the video. The purpose of this video is another blizzard. This one is supposed to be most likely to worse yet. They predict 10 to 14 inches here in northeastern New Jersey and coming down quite heavy. I don't know how much you can see due to the snow blindness, the glare from the snow, but all I see is white. There is the walkway, the porch on the side of the house. It's pretty heavy duty. Coming down thick with a little windchill, which means even more shoveling for me. In the past two weeks, this would be my third shoveling project because of this very severe winter. Very unusually strange severe winter. Thank you very much Greedy Corporations for creating this climate change. Which is causing this. Giving me all this extra work to shovel. It's all pine tree across the street. If it wasn't for the evergreens you wouldn't be able to see just how much snow is coming down. Because then the whole area would be totally glared out from the white of the snow. So that's it. This is the beginning of the blizzard. February 2014. It's not over. I mean it's still early. Definitely coming down heavy. Ah boy. Gee my lower back is going to feel wonderful after this winter season. I might just need a chiropractor. This old man winter is definitely a powerful one. That's all I have to say. I haven't seen a winter like this. Oh gosh. I don't think I've ever seen a winter quite like this to be honest with you. And as a kid I do remember some very heavy snowfalls. So I'll catch you later with the update. Northeastern New Jersey. Yet another blizzard. Okay this is James P. Madonna of Megalife21. And before you saw the yet another great blizzard outside. This happens to be Thursday February 13th 2014. So on a lighter note I just want to show you a difference between a standard compact fluorescent energy saving light bulb. Fluorescent light bulb that you screw in. It's spiral. The difference between a standard one and a daylight fluorescent compact fluorescent bulb that gives off full spectrum light. Now in this case I got it from my plants which I will show you shortly. This bulb is made by a company called Greenlight. And I actually I found these bulbs in a dollar store in my town. It's up and down the entire east coast. It's called the Dollar Tree. It's a chain of dollar stores. Okay so it's a pretty great value. You get like I'd say about 60 watts of light with a very very low wattage. So the energy savings is tremendous. This one particularly is extra energy saving compared to the typical compact fluorescent bulb. Now I'm going to show you my new compact fluorescent daylight bulb. Full spectrum light. I got it at Walgreens. It only cost me three dollars and fifty cents. But it's well worth it because it is going to help beat the winter blues and that's why I'm doing this video. Okay so that's the standard one. I just want to show you the difference. And you see the difference. And this is the daylight bulb that I picked up at Walgreens. Big difference huh. Has like a bluish tint to it. Daylight bulb. Standard compact fluorescent bulb by Greenlight. Back to the new light bulb. Has like a pretty bluish tint to it. And while I'm here I'll just show you my collection of air plants which is known as talancias. They're tropical plants usually from the rainforest of tropical regions. In this case Mexico, Central America, South America. This about in this vase there is two, three, four, I think there's five in here. Yes there are five air plants. They're all together. I have water in the bottom for humidity because they do need humidity. Especially in the average American home it's very dry. Between central heating and air conditioning in the summer it gets very dry so you have to have humidity. It's very important for them. And as far as water goes I soak mine in the aquarium. A heated aquarium which has dechlorinated water. I submerge them and soak them for 30 minutes once a week. Which I usually do on Fridays. And then when you take them out you have to let them drain upside down. It's very important because you can't allow any of the water to remain too long inside the leaves of the plant. It'll actually rot the plant out.  Similar to roots that are soaking in water too long in a standard house plant. As you can see the Ionanthafuego is starting to sprout a flower. There's a spike coming out of the center. So this air plant will get a blossom. As you can see the spike. They all pretty much have this eventually. I'll show you the other plant. This is just my ponytail palm sort of bonsai that I started. They're originally from the deserts of Mexico. Palm trees make outstanding bonsai simply because they automatically by themselves acclimate to the smaller pot. You do not have to wrap the tree in copper wire. You enforce the tree to become miniatures similar to what they do to pine trees in Japan. This is my favorite air plant. I'm not sure if I'm pronouncing it right. Xenografica originally from Guatemala. They're actually very endangered in the wild. They are endangered most likely because of over harvesting. I'm not sure. I think this was capped of bread. It is known as the king of all air plants. As you can see it's quite beautiful. Fuzzy silvery leaves and it's quite large. It looks great with this new compact fluorescent daylight bulb which should speed up the growth and appearance of the plants. I also have water in the vaws of stones that I got at the dollar store. In the summer I will put them on the west window which is very sunny. They will go right on the windowsill with the vaws of water. Otherwise the sun will burn them right out. I'm not sure if you can see that. You can see the difference between the daylight bulb and the standard compact fluorescent light bulb. Thank you for joining me. Okay it happens to be Thursday February 13th 2014. This is James P. Madonna of Megalife 21. Hard of sitting internet radio station on the planet and I'm coming to you from northeastern New Jersey. After the yet another big blizzard. This is part two from the previous video. This is the aftermath of it and I will walk around and show you. Okay it stopped snowing thank god but it left quite a bit of snow. That is dumped. I will show you just how much snow it is since I shoveled. Alright yes the sun just went down and I will show you the conditions here. As well as what the town department of public works of course every year does not do. What they failed to do. Okay there we are. There is the inches right here. Just make sure you can see it. There is a big mountain of snow on the front on the side of the house. Alright as you can see the weight of the snow weighing everything down. And we will focus on just how much we have here. Here is the walkway from ground level. Just gives you an idea. I feel some rain coming down. Now the good thing is the good thing is that the temperature will be slightly above freezing which I hope melts some of this. But I am not sure if that is going to happen since we have so much of it. They did predict 10 to 14 inches but I have not listened to the weather as far as exactly how many inches we got. Just gives you an idea of how much we have. I guess some of it is on the camera. There is a shot from the sidewalk. As you can see there is quite a bit. You can see better here actually. There is the front of the house. It is night time so the lighting may or may not be ideal. There is a car that is buried in front of it. The intersection. Now what this town in southern Bergen County did not do as normally is as you can see. There is a ton of snow on the side of the street here and they do not plow to sides. They only cruise up and down the middle. Snow is normally parking spaces. They don't plow to sides. They just don't do it. There are other cars if you can see it in a distance. Buried also. They are not plowing to sides because they are cronies.  Basically New Jersey. That is it. They don't plow the sides. That gives you an idea how much snow we have. We will see. We will see during the next blizzard. I hope not. Since March is not far away. I hope this is the last blizzard of 2014. Gotta love global warming. Thank you. Greedy corporations. Oil companies. People that are destroying the rainforest of the world. That have caused this climate change. We will get yours in the end. Mother nature. Gaia will get her revenge.


Good afternoon. My name is Atul Kshar Sagar. I'm an engineer at GE Software. I've been working with Cloud Foundry's Diego team as a full-time member for past five to six months. And I'll be talking about how GE Software, in collaboration with Pivotal, is trying to add non-HTTP routing capability to Cloud Foundry. Now, this is going to enable routing of support for IoT protocols in Cloud Foundry, as well as it is going to enable support for any layer 7 protocol that's going to work on TCP. So why is GE interested in IoT at all? By show of hands, how many of you have heard about industrial internet? Wow, everyone has heard about it. That's nice. So now you all know that industrial internet is internet of really big things. It's also internet of really important things. Now, I'm going to walk you through a very typical use case that GE has. And I'm going to show you why IoT protocols are important. And I'll also try to show you how Cloud Foundry fits into this entire scheme of things. So now, most of you would know that GE is a big industrial company. It has its presence in many industries. It's there in aviation, transportation, health care, oil and gas, power generation, many more. So the example and the use case that I'm going to show you today is from our power generation business. Now, this is our typical ITOT deployment and topology that you are seeing here. On the bottom left, what you're seeing is our remote stations where you have those big turbines that are generating electricity. The top left, you see the control centers, which are going to manage these remote stations. And on the bottom right is our data center, which has our industrial apps that run on the cloud platform for industrial internet. Now, if you notice there, in the remote stations, you have those PLCs with a little P on that. That is our predicts machine, which is the embedded part of our software. This predicts machine software talks to the turbines and controls the operations of the turbine using a variety of OT protocols, like OPC UA, Modbus, MT Connect, Profinet, there are many more. If you look at diagram, you'll also see that there are a bunch of sensors which are fitted on those turbines. And they are going to measure various operational parameters, like what is the level, pressure, flow. And that data will be sent to predicts machine or IoT protocol like DDS. This data in the remote station is stored in a time series database, which is a proprietary time series database of GE called Historian. And that data is then sent over satellite uplink to our control centers.  These apps run edge analytics so that that data could be shown to the field engineers, to the experts who are in control center, who can actually manage and take real-time actions. Now, you see there is a little P over there in the control center, which is our predicts gateway. This predicts gateway is going to get the data, compress it, filter it, and send it over when to the industrial apps that are running in our data center. These industrial apps are going to run predictive analytics, do advanced analytics, and give you predictive insights, and then all big data stuff that's going to happen there on. So this predicts gateway, as well as a bunch of apps that are running in control center, are going to send the data to the apps running in the data center over multiple protocols. HTTP, obviously.  Now, let's zoom in into our data center. And this is where Cloud Foundry comes into picture. Our cloud platform for industrial internet, it is called predicts, is based on Cloud Foundry.  Now, the key part here is we have to get the data either from our predicts gateways, either from the apps, sensors, or devices, or to the apps that are running on Cloud Foundry. Now, you get a picture of what we have in terms of our protocol landscape from G's point of view. Let's take a quick look at how the protocol landscape plays out in an regular IoT use case. So Eclipse Foundation recently conducted a survey of IoT developers. And they found out what are the messaging protocols that you use in your IoT solutions? There are two things you should notice about this particular survey. First, obviously it's only not HTTP. There are many more protocols. MQTT is there, co-app, XMPP, DDS, and many more. And if you look real close, it adds up to more than 100%. Why is that? Any guesses? People use more than one protocol in their IoT solutions. It's just not one. There are more than one. And that's the real point I'm trying to make here. World is multi-dimensional. We need multiple protocols. It's not only single protocol that you need. And that is in where we need support for multiple protocols in Cloud Foundry. Now, in an IoT use case, HTTP has certain drawbacks. HTTP has overheads, large overheads, doesn't offer QoS, not very well suited for large payloads, doesn't offer sticky sessions. So those are various disadvantages if you consider HTTP from an IoT use case. So now that we know for IoT, you have multiple other protocols in play, what happens today when you have Cloud Foundry? Now, you have this bunch of apps we have deployed in Cloud Foundry. And let's say these are 12-factor apps, web apps, if you will. And your web clients or browsers will happily talk to your apps, because GoRouter understands HTTP very well. If you want to talk to app one, GoRouter can do it. It knows how to forward the request to your app. And everyone's happy. Now, let's try to see what happens in the IoT use case. In comes our sensor device gateway. It doesn't want to talk HTTP. It wants to talk maybe MQTT. GoRouter has no clue. What do I do with this? Well, I can't do anything. Connection drops. Everyone's unhappy. So now, if you have to use Cloud Foundry, you have to use it in an IoT use case, what do you do? There's an even no answer to existing. What is the workaround? CF services. That's what people do. You will host some part of the system or some part of your app outside of Cloud Foundry. That is the part that's going to receive the data over non-HTTP. And then you use CFS service broker APIs to expose service endpoint into Cloud Foundry. Now, the apps will bind to that service endpoint, get the data. All works well. But it turns out there are certain drawbacks. First up, you are adding an additional hop to get the data. So there is an additional latency. Second, you have to manage that part of your service or app outside of CF. So you don't get all those things that CF is offering you. It's not going to manage the health of your apps. It's not going to move your apps if your apps crash. It's not able to scale. So you have to do that by yourself. But most importantly, it's not going to work for all the protocols. MQTT here, what I have shown here, it will work very well because it's a broker-based protocol. You can have your broker outside of CF and apps as client to that broker and everything works fine. But what about peer-to-peer protocols like DDS? Want to put your apps out there? Then what's Cloud Foundry for? It's not going to work. So it will be great if Cloud Foundry is going to have this capability to route non-HTTP traffic directly to the apps. If you have that, you will take Cloud Foundry one step closer to make the platform of choice for IoT use case. We want that. So now that we know for GE, definitely IoT is something that is required. And this is a gap that needs to be filled. Let's see how we can add this capability. And as any good engineering team, we came up with a couple of options. Let's have those options. Let's see what is involved in that. And let's pick the right one that's right at this point in time. So I'm going to walk you through those two options, give you a brief overview, and then we'll take a deep dive into the approach or option that we have decided to go with. The first option that we considered is layer 7 router. Existing HTTP or Go Router that we have is layer 7 router. So we thought, that's nice. We can just extend that. Might as well put a routing framework around it so that you could have pluggable layer 7 protocol specific proxies. So you could have a proxy for MQTT. You could have a proxy for EDS. You could have a proxy for XMPP, and so on and so forth. And this routing framework now will route the traffic that it receives on its external port to the particular proxy. So let's say it receives traffic on port 1883. It routes it to MQTT. So that routing could happen based on what is the well-known port for that particular protocol. Now, it's the responsibility of that proxy to actually route the traffic to the appropriate instance of the app. And how it is going to do it, I'm going to talk about it a little bit later. And that's where the more challenges are. And we'll see what those challenges are. So now, if you look at this approach, the advantages of this approach are pretty clear. Oh, you are going to use standard ports. It's very natural to use. Like you're using HTTP, AT, and 443. You'll be able to use MQTT on 1883. You'll be able to use XMPP on 5222. It's very scalable. There is no limit on the number of apps that can receive this non-HTTP traffic. It's very extensible. You can add support for whatever protocol you want by developing a proxy, plugging it in. You can develop some routing services. Like we are going to develop for Go Router. We have this router services that will be developed. And you can implement any cross-cutting concerns at that layer 7 protocol proxy. On the flip side, you'll see that you need to develop protocol proxies for each individual protocol that you need support for. So that is obviously an additional overhead and more complexity. But more importantly, and this is where we'll dig a little deeper into how we can have this layer 7 proxies route the traffic to particular app instances, it's very difficult for this proxies to know where it should route that particular traffic to. It will end up using some non-standard ways or some hacks in order to achieve that. So let's spend some time on this to understand what's involved and why is it so complex. In case of HTTP, it's relatively easier because HTTP specs mandate that you need to have the host header in your HTTP request. What is this host header? This host header is your route. It's your app1.cfapp.com. That's going to come in your HTTP headers. So Go Router can look at this host header, look at its routing table, and route the traffic to particular app instance. Let's take a look at the headers from one of the IoT protocols. I'm picking on MQTET here because that's more popular. That's what we saw in Eclipse Foundation survey. MQTET has two byte fixed header.  Second byte is remaining length. It's followed by a bunch of variable headers which are different based on what message type it is. The most relevant message type for this discussion is connect message type, which is the first message that will be sent by the client to the broker in order to connect to the broker. So here, the variable headers would be protocol name, version, connect flags, and keep alive timer. After this is going to be the payload. So if you look at these headers, there is nothing similar to host header in HTTP. So there is no way for MQTET proxy to determine what is the logical target just based on the standard protocol headers. So now it has two options. It can add its own custom headers. An expected client will have that custom headers in it. If you do that, you need client-side updates. Existing clients are not going to send that header. Can you do that in IoT? Maybe, maybe not. It's not probably practical to go and update hundreds and thousands of your devices with client-side updates. So what do you do? Then you'll have to come up with some non-standard hacks and some tricks, depending on who you ask. And the case in point here is SSH proxy. The SSH support that we are adding to Diego, how it is achieving the routing of SSH connections to appropriate app instance. What it does today is that it expects the username to be the process good and index. And then it knows, yeah, this is the process good. This is the index. I know I can look up in the routing table. I know what host IP and port it is, and then I can route it. So now the clients need to provide the process good and index as the username. Now, it would be a little bit better on the SSH side, because we are going to provide the SSH plug-in on the CLI. So user is not going to worry about that they have to find out the process good and index and all that stuff. IoT is going to be difficult. But there, now we have to see if there is any other easier way that we can achieve this kind of routing. And if there is an easier way, we should probably go with that and see how that plays out. And as it turns out, there is an easier way. We can do layer four routing. So when we were looking at these various options, Pivotal was also looking at routing SMTP traffic to its app, and it was considering the same particular option. So we collaborated, and we detailed this particular approach out. And this approach is pretty simple and straightforward. Here, what we are going to do is that we are going to map the external port of a router to a particular app. What that means, let's take an example. Let's say there was an app 2, and it wants to listen on port 5222. It wants to listen for SMTP traffic. So it maps itself to port 5222 of TCP router 1. And it gives out the front end IP of TCP router 1 and port 5222 to its client. And that's what it will use to connect and talk to app 2 over XMPP. Now let's say there was another app, app 4. What's it listen on port 5222? Now it has two options. It can either map itself to some other port on TCP router 1 and give out the front end IP of TCP router 1 and that non-standard port to its client so that it can talk to app 4. Or if it is not very tolerant or the clients are not very tolerant in terms of using non-standard ports, then it can map itself to another TCP router instance, which has a different front end IP, and map to the same port 5222. So the idea here is you use port address mapping or port address translation. And by virtue of receiving the traffic on that port, you would be able to know which app this traffic is meant for. And I promise we'll go more detailed and see what it actually takes in order to do all that. But at this time, I think it's good to take a look at what are its pros and cons. You are going to get support for almost all layer seven protocols from the word go. You don't have to write any proxies. You don't have to worry about coming up with some non-standard ways of developing routing mechanism for that proxies. Complexity is highly reduced, of course. On the flip side, you might have to use non-standard ports for your IoT protocols. The major concern here, though, is about scalability. Now there are two type of scalability things to be considered here. One is if you are tolerant towards non-standard ports, then you are limited to 64K theoretical number of apps that can receive non-HTTP traffic per router instance. But the workaround for that would be to have many more router instances in your deployment, and you can overcome that scalability issue. Other is more serious, as in if you are not tolerant towards non-standard ports, then you are limited by the number of front end IPs your IIS can give you. And there is really no good answer for that unless your clients are tolerant towards non-standard ports, in which case, I mean, as things evolve, we might go with a hybrid approach. But as of now, this is the one that we are going with. And as I promised, I'm going to dig a little deeper and take a little closer look at how we are going to develop support for this TCP routing in Cloud Foundry. If you guys have attended on-site stock in the morning, he indicated that TCP routing is going to be part of Diego. And what that means is that it's not going to be available for apps that are running on DEA. This will be developed based on Diego and will be part of Diego. So one more reason for you guys to adopt Diego. So this is the architectural block diagram of Diego. I'm not going to go into details of this, but I'm going to talk about the new components that we are going to add. There are two new components that will be added. First is the TCP route emitter. Now, this is a logical component, whether it becomes a part of existing route emitter or is a separate component is to be determined and will decide that as we execute. But functionally, what this TCP route emitter is going to do is that it's going to subscribe to server-side event stream from Receptor, which is going to let it know about changes in actual and desired LRPs. What that means is when app is placed or app gets moved or app gets scaled, we'll be notified about it. And then the route emitter is going to get that information and give it to TCP router, which is going to maintain the routing table, which is the mapping of front-end IP and port to your back-end IPs and ports. So as soon as the data is received, it will be able to route to the appropriate app instance. Now, if you'll notice here, I have added TCP router and TCP route emitter as part of lattice, because this will be packaged as part of lattice. And that is going to be our first deliverable. We'll develop these components, and we will ship it as part of lattice. So your lattice apps can receive non-HTTP traffic. So there are, obviously, a lot more things that are involved and that lot of things that we need to consider. And I'm going to talk about all of them. But by no means, this is an exhaustive list. I'm sure if Shannon is here, he is going to add a lot more. He's our PM for this project. Obviously, we are going to route TCP traffic, and I'm calling out TCP here because we are not going to support UDP at this time. If there is a need and there is a requirement, we will add UDP support in the future, but that's not on cause as of today. One of the important things that we are going to consider is zero downtime. Whenever there are config changes that are happening, when a new app gets placed, app gets scaled up or down, we have to make sure that the existing connections do not go down. Now, depending upon whether we are using HAProxy for TCP router, Switchboard, which is our existing TCP router that's used in services, or we write our own, that's one of the main things that we will be doing. We will make sure that there is zero downtime for existing connections. If you have more than one app instance, we will be providing you a way to do some load balancing, either round robin, weighted round robin. We will be providing a way for doing health checks. So we don't want to route the traffic to an app instance that's down or it's crashing. We want to make sure that we route it to an app instance that's up and running. We will be providing some kind of traffic shaping and limiting number of connections that can be made simultaneously. What is the connection rate? So those things can be controlled. We have to manage back and forth so that we don't run out of the back-end ports. And that could happen because of buggy TCP clients. It don't close the connection. The ports go into FinVet 2 state, and then we run out of ports. We have to manage rolling deploys so that we give enough grace time to the existing apps and clients to shut down their existing connections gracefully so that those could be upgraded. Obviously, we have to provide a way to reserve the front-end IPs and port combination. That's going to be achieved using changes to call Cloud Controller. And now Cloud Controller is going to make sure that there is no conflicts. If there are two apps trying to get front-end IP and port combination, it will detect that. It will prevent one of them. We'll provide a way for you to add, remove, and show these mappings. So that means CLI changes will be done. And you would also be able to do this mapping for front-end IP and port using application manifest. So I would like to conclude here by just calling for your feedback and comments from the community. And we would like to especially hear about your IoT use cases or any use cases that need non-HTTP traffic. And I put up my contact information and contact information of Shannon, who is the PM for this project. We would be glad to hear from you and we're looking forward to add this functionality to Cloud Foundry to make it a platform of choice for IoT. Thank you. We have four more minutes for questions or I have a demo, whatever you choose. Yes, so the way we authenticate devices is using client certificates. And since this is going to operate at layer four, we would be able to flow the client certificates all the way to the apps. And apps will be able to authenticate using the trust flow that they will have. When it, so we should start off next week. I don't know if Shannon is here. Yeah, Shannon is here, if you could stand. We would get started next week. And as soon as we have certain stability will, and it would be part of Cloud Foundry incubator, should be available for anyone and everyone to see. First up, it would be available as part of lattice for you to play and see how it goes. We have time. And this is against all the advice that I have got of not doing live demos, but I'm going to do it anyway. So what I'm doing is that I'm doing a Bosch SSH into one of the cells where I have already pushed an app, which is actually nothing but a Netcat server. It just listens on port three, four, five, six. And it just listens for anything and everything that you are going to send to it. Oh, sure. What I'm doing now is that I'm going to go into, I'm going to go into the container and I'm going to show you the process that's running. This is the app. Well, it's a Netcat server listening on some port. And it's, whatever it's getting, it's putting it into a file. It's putting it into a temp output. I'm just gonna, and I'm gonna hop up here and I'm going to open a connection. So as I said here, if you see this, first is the front-end IP and the port. And I'm gonna say Cloud Foundry Summit rocks. We received that here. So we will be able to, yeah. So we'll get this and obviously we'll, this is obviously a POC that I put up together for this stock. And this will all come together in a nice way which you can use. And it would be available to, I hope you give it a try, give your feedback and glad to hear from you. And I'm hoping we'll be able to get this functionality out as soon as possible. Thank you.


Okay, hello again, and welcome to this talk on open source metrics and analysis. As I said, in the first iteration of this, this is meant to be more of a beginner's guide and introduction to working with data and metrics around open source projects. As you can see, I am a program manager at Google focused on research and analysis. For those who aren't here in the room today and can't find me to ask questions later, you can find me on Twitter and reach out with questions, comments, feedback, all of the above. My quick background is that I started my career as a market researcher at Forrester, writing surveys, writing data, sorry, writing reports around that, and then consulting with technology leaders and sellers and builders, buyers, move more into a data and analyst role and now program manager within our open source programs office. So the continuous factor across all of these things is I've worked with a lot of different kinds of data. So that's kind of the theme of the talk today, is working with and around open source data. And the central comment is data is really messy. I don't know if anyone's worked with a perfect data set. I would love to know what it is and how I get my hands on it, but mostly every data set that I've worked with has had some kind of issue, whether or not it's the systematic issue, the way you've processed it, the way you've set up policies around it, maybe sort of access levels or gradations of access. If you work at a company, you don't have the right authority to see certain pieces of things. If you've ever written a survey, there's always the inherent bias that comes into building a survey, designing panel, filtering for that panel. And then the person taking the survey, how do they actually feel on that given day could affect how they respond to your survey? So there's always going to be issues and ambiguity in terms of how you collect data and around surveys, public data, some issues like you would see in businesses, reporting gaps, systematic issues, policy issues. I had my first internship working at a private equity startup, trying to trend research. I had to trend things in industry looking at 10Ks year over year, and if anyone have noticed, but you don't necessarily have to report on the same metrics every year. So there's a lot of inconsistencies, even in public reporting and public data sets. Now, about a year and a half ago, I started working with the open source programs office, and I was brand new to open source at the time. I kind of understood the concepts, but was fairly new to the space, fairly new to working with data around it. And in addition to all of those challenges that you might face working with data, open source has even more ambiguity, even in the way that we define a project. We could be talking about a code, code base, software, data set, framework. If you work with open source hardware, it could be a series of designs and processes to build something out of that design. I also work with the chaos community, where we talk about metrics, and that is sort of our end product is metrics and language around how to talk about metrics. And so even our definition of project can be quite various. And then in terms of how you even define contribution to it, that's a whole other can of worms that I will save for another talk or refer you to another piece of research. This is, I'm pointing to a couple of links throughout the doc. The presentation, this one is particularly a piece of research that came out of the University of Vermont that talks about how different contributions are counted and the methodologies that allow for understanding contribution models around projects. Particularly when it comes to working with source code logs, the biggest thing that I found with them is that there's a lot of inherent inconsistencies and gaps. One of the main ones that I found out early on in the process is that it's possible that your current records and historical records will not match, and this is because of when you actually pull the data around your project. I learned that if your project has been around for a couple of years and your fork now gets merged as part of the main branch, that fork will overwrite all of your existing historical records around the project. So if you're writing a query looking at a same time period and you re-pull the data and you write the same query, you could get different results, which I found kind of shocking as someone who's worked a lot of data that historical data can actually change in the context of source code logs. If you've worked with GitHub APIs, you might have bumped into some rate limiting that could result in lost or missing data, not to mention that the schemes and the logs can have different sets of things that they're measuring, when they're measuring them, and even what you're counting and how you're counting it. So GitHub alone has multiple different types of APIs, the event stream issue stream, web stream, not to mention other tools, have different things that they're measuring. If you've worked with Garrett data, it mostly focuses on changes and reviews and change logs, where GitHub has a whole issue stream that talks more about bugs, issues, triaging, and comments. A quick example of some inconsistencies you might see is a very simple query I ran on GitHub Archive, which is a comprehensive collection of the GitHub event stream, looking at a query that should have similar results for all of these tables given that they're on the same time period. But as you'll note, these are not the same number. So we know something is missing. We don't know how much is missing. We can have a rough order of magnitude based on the variation that we see in the same time periods. But how do we make this better? This is a topic of conversation that we have around this project and around open source data collection overall. Another part of the problems here are working with bots. In other kinds of data sets, there's always going to be machine data, but I found working with source code logs, there's a lot more automation in bots that are woven into what's being collected and what's being actually collected as activity around a project. Bots could be labeled as bots, but they also could be scripts coming from personal-based accounts. And then you can run into the challenge of maybe something is broken and causing a lot more activity. I have a personal example here working with looking at our contribution data across Google. I ran into a problem where I found there was an individual account that was responsible for over 40% of push events in the month of July. So I thought, well, that's pretty large given that there are thousands of people at our company that are working on tens of thousands of repositories and, say, generating hundreds of thousands of push events every year. And so 40% actually represents a large number. So I reached out to the individual and found out that this was just a broken mirror that was trying to copy things and failing. So it just kept trying to do it and it kept failing. And so even you can see kinds of activities like this that are causing a lot of noise in your data that don't actually represent real data at all. Just for a little bit of context, I was curious to know how many bots there are in GitHub Archive in 2020. I wrote a super basic SQL script that you can kind of see the structure of below where I'm identifying bots by finding BOT in the actor login until your handle. So if anyone in here has a handle with BOT in it, I'm counting you. So know that there's a little bit of flaw here. So we estimate that using this script, there are over 120 million bots that log activity on GitHub, the GitHub event stream as per GitHub archive in 2020. And for some examples, you can see the top 10 that popped up, Dependipot, GitHub actions, pull bots. Thank you to everyone who's put bot in the title because right now this is the best way we can actually identify it on Macs. People. So I want to talk a little bit about how people introduce additional complexities in the data that we're looking at. Clearly, most of these things are designed by humans, so there's always going to be some influence and flaw that we bring to the design itself in terms of how we create it, how we control it, our personal backgrounds, experiences and feelings, as well as the policies and processes that we put in place to govern it. In particular, in open source, I want to talk a little bit about there's different people at different layers that are impacting what you might see and when you might see it, say the user or contributor that's generating it, they can create their own handle, log in, use it however they want to, or call it whatever they want to. The source of the platform that collects the information, they design policies around how things are collected and what are displayed. The collection mechanism, if you're working with a tool or a pipeline that's building these things for you, if you're the collector or maintainer, then you also have choice in terms of how you collected, how you store it, how you access it. And then, very personal to me, the last piece is communication, how you talk about data and how you create content around it. And each of these individuals at each of these layers has a choice in how they interact with the data, how they set it up, and essentially ingraining either bias context or systematic nuances in terms of how the data itself was collected, presented and discussed. Additionally, with open source, there's less clarity with who has accountability for what. So I have the pleasure of working with a large company and we are beholden to policies that govern the data that we collect around our employee base, our user base, and any regulating body that we work with that influences how we design these policies and practices. In open source projects, there's a lot less clarity of where these boundaries are and who's accountable for what. And there are people sitting in the middle of this, it being subject to policies that are coming from companies, from organizations and government organizations and projects, but it's more just to a call out that it isn't always as neatly defined as it would be in terms of working with a company. There's also the issue of PII. So anytime we're talking about data privacy and data sensitivity, at the core of it, it's who people are and what information that they are comfortable sharing it in what context. And something that I love about open source is that we have the ability to participate without revealing ourselves. We can be anonymous if we can choose to be anonymous. We can choose to have multiple identities. I personally have two GitLab accounts. One that's used for personal reasons, one that's used for work reasons, and there are probably many other reasons why you can have multiple identities in places. So even though you can choose to be anonymous in a lot of these contexts, there is a number of pieces of research that are investigating the minimum number of things you need to know about a person before you can actually figure out who that person is. And I would stress, especially for small projects, even if you're trying to be completely anonymous with all of your data collection and visualization, depending on the size of your project, you might be able to figure it out who it is anyway. So just being sensitive about how you're portraying information, how you're collecting it, to ensure that everyone is sort of being kept in the boundaries that they want to. And I will say there's always going to be use cases for why you might want to collect PII and share it. Some projects use a contributor activity as a way to inform who gets nominated for the election process in a project. Maybe if you're working on a diversity equity inclusion initiative, you need to understand who your groups are represented and what you're underrepresented to know how you want to invest in that community. But at the end of the day, when we talk about actually sharing this data, I always want to caution what you share potentially might influence what you're actually measuring. I like to draw correlations with natural sciences if possible. If you're familiar with the quantum entanglement principle, any measurement of a quantum entangled particle will irreversibly change the properties around the original quantum state. So you literally cannot measure it without impacting it. And this comes true. This is mostly true, I would say, with things like reporting and metrics. Say you are creating a leaderboard and you're showcasing the number of commits around a project. Now, you could be inadvertently encouraging people to create more commits versus, say, working on other elements of the project, like issue triage or event management. So not to say that you shouldn't report. In fact, I highly encourage it. Just do it purposefully with the sense of an outcome that you're trying to achieve. If you're working toward community growth or community contributor diversity, being very transparent about what you're trying to achieve and measuring against that goal as a way to at least incentivize the behavior that you want versus the behavior that happens as a result of it. The last piece, which is probably the stickiest issue. And so I will be brief with it without overstating. Again, I am an analyst. I am not a lawyer. So when in doubt, involve the lawyers all the time. This is my recommendation here. But I mostly want to mention that a lot of the data that we're working with is subject to terms, policies, licenses. They may or may not exist, but when they do, it's important to know what they are, how they apply. They could come from the data set, from the project data is around, from the tooling, from the platform, privacy policy documentation of all of the above, regional regulation, country regulation, probably other layers that I'm not even thinking about. This is just sort of the general starting place with ensuring that you are allowed to use the data. You're allowed to show the data and that you are assuming responsibility for what you're collecting. I found this resource thanks to a colleague resource at the bottom, which is thinking about how you exchange technology and information internationally. The Linux Foundation actually put out a report last year to help guide folks that are thinking about moving things across borders and understanding the policies and regulations at play. Bringing back sort of the persona conversation, I wanted to bring it into this because of the multiple layers of policy and regulation that can come up during data collection and management. Say the user themselves has the ability to opt in or opt out, share or not share their information. So that's a personal choice, but then the hosting platform themselves, saying something like GitHub, has an entire set of privacy documentation that specifies how data can be collected, used, and all the regulatory requirements that it's subject to. Now, it doesn't stop there. So now that you've started to collect it, most platforms that collect data are inheriting the policies and practices and licenses that are ahead of it. So even if it's not stated in that tool, you have to know that the licenses that things are coming from still apply. So it becomes a sort of nested and inherited progression. Now if you're the entity, say myself working at a company, collecting data around projects, we're also now responsible for where the data ends up in terms of the infrastructure selection and ensuring that that complies with local regulatory requirements, data sovereignty, other issues that could come up when, at any time you're storing data, especially PII about individuals. So knowing what those could be for your company, for your project, and again, if it doesn't really exist, then maybe this is an opportunity for the governance or leadership boards and committees to talk about how they want to maintain data in and around their projects. And that's sort of the last piece. I've worked with a number of projects and spaces where there is not a lot, there's a lot of this is not defined. So we're trying, we're hunting, we're going to find out what things should we actually know about this data, about the projects that work with the data? Does it exist? Maybe it should exist. And in places where there's a lot of open white space, there's an opportunity for project leaders to create it. So I worked with the chaos community I mentioned earlier, and earlier this year, we've been working on our own privacy documentation. And this came up when we started collecting data for our diversity and equity inclusion and badging program. We started collecting more sensitive information about people and attendees. And we realized that we needed to have a way to hold ourselves accountable and a way for us to be transparent with the community around how, what we're going to do with their information and how we're going to maintain the integrity, security, and privacy of that information. So a lot of it in this case is just about being transparent, declaring your objective, saying why you're doing it. I think people are generally a lot more willing to share information if they know what you're going to do with it. They don't want to be exploited, but they do want to help you create a community that's welcoming inclusive of a variety of individuals. So the call to action here is if you don't find anyone accountable and you're collecting data, it's probably you. So it's good to have these things in mind. And again, if you can involve your legal teams, if you have the luxury of having lawyers available. So the last couple of slides, I want to talk a little bit about what do we do now? What do we learn? How do we implement these things? Starting first with sort of the perspective of the analysts, I'm going to call these good data practices. I think best is a strong word. And I think this is a learning practice will continue to get better. Always state what you're counting. I like to think about if I were to say this thing in isolation, can someone else recreate the metric and confirm and get the same result that you have? It's okay to use descriptive terms. I know there's probably writers in the audience that like to be a little bit more creative with how they describe things. I think that's fine as long as you define what you're talking about. So maybe providing some sort of glossary or appendix that actually defines how you're accounting contribution or engagement. It's very important to also state your sources including any methods, assumptions that could introduce bias or boundaries around what you're looking at. Are you looking at only GitHub data? Are you looking at data from a number of different sources, a number of different communities, populations? It keeps expanding. So always state your universe in a way how that information was collected and what does this represent within what you're trying to convey? I have an example here. I recently wrote a blog that included about the data section where I supply some information around the terms and the sources. If you've worked in the academic community there's a lot of existing templates around how to talk about your data and the process in which you arrived at your analysis. And outside of the academic space it's sort of again up to you how you do this. So this is just one example of it in practice. I always wanna mention too that as an analyst it is very easy to mislead with metrics. People really like numbers but if you remove the number from the rest of the context it can be taken out of hand or just harder to understand or harder to contextualize. So I wanna come back to this bot example that I mentioned earlier looking at the number of bots on GitHub archive. So I pulled another query that looked at how many pull requests events were triggered from bot-based accounts based on that designation and found that 38 million pull requests events in 2020. Now there's something missing here. What is it first? Maybe it's where I'm pulling the data from okay so now we're talking about pull request events on GitHub in 2020 but maybe there's 38 number. I don't really know what that means. Is 38 million a large number? It could be, maybe it's not a large number. So I started to look at the total number of pull request events on GitHub in 2020 and then looked at the bots as a portion of that and found that it was 44%. Okay that's actually quite substantial. It's almost, it's under half but it's nearly half of all the pull request events that were logged in the GitHub event stream. Now, okay is that, I know more now but I think I wanna know a little bit more especially after I looked at this 44% number I was really curious, okay what was it last year? So I provided another query that looked at it was only 25% in 2019. Now personal anecdote here, this actually really piqued my interest so I just kept running the same query year over year and found that in the year before 2019, 2018 it was 6%, 2017 was 3%. So that's actually really significant growth almost exponential depending on how you define it and what metrics you're looking at but point of investigation for a later date. It's more of the more context you provide now the sentence actually holds a little bit more water it holds a little bit more context. One thing that I think is missing from this is that this is also an estimate. This is not a real number. I mean it is a real number but it's not a hard in fact true number because of all the inconsistencies we know about the data collection process as well as how I pulled the data. I explained the query I ran earlier which if anyone has BOT in their handle or count to you so it's not just bots. So I think somewhere you might wanna write in it that how you're defining this where you're actually getting the number this could be an about section and just again trying to provide more information more context because I think numbers can be a really powerful tool to influence toward achieving an objective but if you leave things out they don't really mean a lot. The last section I wanna mention is just there's tools you don't have to do this all of yourself you can if you want to but there is some open source tooling available in the community. Again chaos has a number of projects grimoire labs and auger that are designed to help you build a pipeline or even a full visualization layer. We've also worked with CNCF DevStats they use Grafana as the visualization layer with the SQL database on the back end. So my last slide on recommendations is again assume you're accountable if you don't find anyone else to point the finger at or to go ask questions to assume that it's you so that you can answer all of these questions on your own in terms of knowing the licenses and policies that are at play. If you are collecting information where it hasn't been collected, displayed and discussed before maybe it's wise to state your intent and the purpose for why you're collecting this information how you intend to use it and how you intend to protect this information such that people feel comfortable sharing it with you. So really encouraging transparency especially in open source we want to understand each other we want to grow and make things better and part of that is by building trust and being transparent with why we're collecting information especially within say providing enough in and out was from scenarios some people don't like the information to be collected they don't know about it but they have the opportunity to say yes then it's always worthwhile to make that distinction and then I always call out for the researchers in the room do you really need PII? This really adds another layer of complexity and what you're doing with that information so if you remove it all then you remove a lot of liability in terms of just having any kind of exposure potential and again there are definitely use cases where knowing PII helps you with your analysis I know there's a piece of research I looked at that was looking at social models around projects where we wanted to understand the social networking components around productivity and software development in open source so that is a case where you need to know who the people are to understand the connections between them but if you're just looking at aggregate trends, stats and changes and how things are being built you probably don't need PII so that's the end of my talk I don't actually know how much time I have I might have one minute one minute maybe one question yeah absolutely so I'm gonna try to put my answer with your question in it because I won't repeat the whole question in an unlimited amount of time but understanding how to interpret what you're looking at is sort of how I took your question I'm a big fan of reading the methodology before the results I know a lot of white papers want to put the flashy findings up front to catch your attention and get you involved but often they don't mean a lot until you know where they came from to your point so I like to peruse the methodology section make sure you understand the sources make sure you understand the thing that they're looking at and to your point most reports are built on some sort of subset of information or a survey that was run to 200 people in this year so there's always gonna be constraints around information gathering which is just the nature of the game so I would say recommend for anyone looking at it just know what those are and try to understand them if you can if there's other existing sources that look at similar things you can start to compare their methodologies compare what they've done in order to make those assumptions if you look at academic research again it'll generally all be there because that's part of the process and writing up academic findings but in white papers it's a little bit less transparent so I would say if there's nothing there I would reach out to the writer and say give me more because I think it can be very easy to just state something not necessarily have a full picture so I think I'm gonna be migrated off stage now so I'd like to welcome my next speaker with one more plug to other talks about metrics at this event if you are hanging around and interested in that topic


happens to old prosthetic sockets? Can we donate them to other amputees? I wish unfortunately the answer is no. Throughout the amputee life cycle you're gonna have a lot of different sockets if you use a prosthetic because over time your limb changes size and shape. This is my current socket this is one that's too big. However unfortunately donating this would be pretty darn useless. The way that your limb is shaped, that the bones are shaped underneath is so unique to you. No two amputees are the same. So for the most part old sockets just sit in our closet maybe that's just me. Now certainly in more desperate situations could you retrofit an old socket and become someone's new one? I'm sure you could. I'm also fairly certain that that would be really uncomfortable. In a pinch it could probably work but in general once a socket is outgrown it's into the trash or collecting dust. There's got to be a way to recycle these. I'll look into that.