Welcome back. So, today we will discuss Borel-Cantelli lemmas. So, Borel-Cantelli lemmas say that if you are given a sequence of events, it gives conditions under which only finitely many of these events will occur. I will stated properly now. So, as usual you are given a probability space. Some omega f p is given to you. So, there are two Borel-Cantelli lemmas that we will study. There are actually a few more versions, but we will study the two most famous ones. The first Borel-Cantelli lemma says the following. If a 1, a 2 dot dot dot is a sequence of events such that sum over n equals 1 through infinity probability of a n is finite. Then almost surely or with probability 1 only finitely many a i's will occur. So, a 1, a 2 dot dot dot this is a sequence of events. So, they are all f measurable. So, all these events will have some probabilities associated with them. So, if it so happens that the sum of the probabilities of a n, n equal to 1 to infinity is finite. Then the Borel-Cantelli lemma 1 says almost surely that is with probability 1 only finitely many of the a n's will occur. So, I will help you digest it a little bit better. First I want to. So, there are only two possibilities for this summation. So, probability of a n is a non negative. This is like a non negative sequence. P of a n is a non negative sequence. So, if you sum a non negative sequence n equals 1 to infinity it is well defined. It is always well defined. The question is whether it goes to something finite or goes to plus infinity. There are only two possibilities. So, the first B C lemma talks about the case when it is finite. The second Borel-Cantelli lemma talks about the case when it is infinite. We will first deal with in this finite case. So, I will help you parse what this finitely many a n's occurring means. The second Borel-Cantelli lemma I will just state both and then explain both of them. So, this is like a partial second Borel-Cantelli lemma is like a partial converse to the first B C lemma. So, it says that if this is infinite then infinitely many a n's occur, but not quite. You need independence. Here you do not need any independence. Then almost surely infinitely many a n's occur. So, these two are the statements. First Borel-Cantelli lemma says if the summation of the probabilities is finite only finitely many a n's will occur. The second says if the summation is infinity and you have independence then infinitely many a n's will occur with probability 1, both the probability 1. So, let us try to understand the first Borel-Cantelli lemma first. So, you are looking at. So, you can look at this guy. So, probability of a n as some sequence p n some numbers p n with some 2 something that is finite. So, what you have really is a sequence of events whose probability is going down to 0. Because if you know that if a series sums to something finite the nth term has to go to 0 that you know, but the converse is not true. So, you have a sequence of events which is becoming more and more unlikely. So, in that case. So, it is not only true that p n the probability of a n is going to 0. It is also true that the sum is finite which is saying more than that nth term is going to 0. So, you have the sequence of events which are becoming more and more unlikely and they are becoming more unlikely rather fast. So, that the summation is finite. So, which means so this implies that beyond a certain point beyond some finite let us say n naught none of these a n's will occur almost surely. There exist some n naught beyond which none of these n all these a n's will fail to occur because they are becoming so unlikely. So, that is what this means. So, there so finitely many see finitely many a n's will occur means some a n's will occur, but beyond the point there exist some n naught beyond which none of these a n's will occur that is what this means. Similarly, for this part if you are talking about infinitely many a n's occurring that means what. So, you go as far as you like as begin n as you like, but beyond that n there exist at least some a n that occurs no matter what and you look at that is what this finitely many a n's and infinitely many a n's occurring means. This is intuitively everybody with me. So, I will introduce some notation to make this more formal. So, I want to talk about see I am both this lemmas talk about some event of only finitely many a n's happening or infinitely many a n's happening. So, I will actually denote that. So, there is a particular notation for it. So, event that infinitely many a n's occur this is what I want to characterize. So, I want to write this as some unions and intersections of a i's and that is done as follows you write n equal to 1 through infinity union i equal to n through infinity a i. So, it is a nested is an intersection and a union this event is called. So, this is denoted often by a n infinitely often this is simply notation for this event. This is an event that we will encounter a few times. So, this is just denoted by a n i o what this means is just this. I will help you pass this in a minute, but you will agree that since a i's are events and I am only taking countable unions and intersections what results will also be a event. Because, this is just countable union and intersections of these a i's. So, it has to be f measurable. So, this is also an event and I can genuinely refer to it as some event for which I can assign probabilities to it is that clear first of all. So, what the Borel Cantile lemma 1 says is that this event has 0 probability in this case and has probability 1 in the second case that is what the B.C. Lemma says everybody with me of course, I have to explain to you what that all these intersections union means. So, I will help you pass this as follows. So, let us make a definition let B n equal to union i equals n through infinity a i. So, then I have a n i o is equal to intersection B n correct. I am just so this guy here this guy here I am calling B n to help you pass it. So, whenever you have this nested unions and intersections actually in your homework you will see three of them in one homework here there is just two. What you do is you start from the most in a most union on intersection and then work your way out. So, I am going to call that B n I am indexing it by n because I am starting from n here. So, what is B n can somebody tell me what in words what B n is at least. So, B n is the event that at least one of a n a n plus 1 a n plus 2 etcetera occurs that here at least one of a n a n plus 1 a n plus 2 etcetera occurs that is B n. So, for that reason B n is sometimes referred to as the nth tail event nth tail event right it is saying that from n onwards at least one of the a is occurs a n a n plus 1 a n plus 2 one of them at least one of them occurs. And then what is a n infinitely often. So, it is just the intersection of these nth tail events right. So, this is the event that all the B n's occur for every n B n occurs correct by definition. Now, B n is again the nth tail event which means for every n at least one of a n a n plus 1 a n plus 2 etcetera occurs correct. So, which means no matter how big your n is I will have at least one of the a n's after that n right occurring is that clear. So, no matter how far I go no matter how big let us say my n naught is beyond that n naught one of these a i's will still occur correct this clear to everybody. So, the first barrel cantile lemma says that a n infinitely often this event has zero probability in this case. The second barrel cantile lemma says this event has probability one in this case are there any questions at this point before I prove these results. The proofs are actually fairly elementary once you manage to understand what it is that the lemma says the proof improving it is not very easy difficult. So, a i's so this I have defined B n as the union from n to n to infinity. So, this is B n is the event that at least one of a n plus a n a n plus 1 a n plus 2 etcetera occurs right for the given n right. So, it is called the nth tail event. So, given n it is the event that at least one of a n a n plus 1 a n plus 2 etcetera occurs and this is the event that each one of the B n's occurs which means for every n. So, I will say that this event has occurred if each of the B n's occurs which means for every n I must have a at least one of a n a n plus 1 a n plus 2 etcetera occurring correct for every n I need at least one of a n a n plus 1 a n plus 2 etcetera occurring any questions proof B c lemma one is very easy to prove. See remember that first Borel continue lemma does not need independence or any other further constraints right. If it so happens that sum over n equal to infinity p of a n is finite then this will apply only finitely many a n's will occur. So, what do I have to prove I have to prove that in the first case this event has probability 0. So, that the complementary even finitely often we have probability 1. See what is the complement of this will become this intersectional become a union then the union become an intersection and then you will have a complement right which means there exist n n such that each of the further a i's fail to occur which is what finitely often means right. So, you can just use demorgan and flip this around you want. So, if the first Borel can tell lemma. So, you have. So, you want to look at this right you want to look at probability of essentially this right you want to show this is equal to 0 right and what is the if I see something like this what is the first thing I do I invoke continuity of probabilities. Now, this B n's I think this B n's will turn out to be nested increasing or nested decreasing B n's are. So, B n is the event that at least one of a n a n plus 1 etcetera occurs. So, B n plus 1 is so nested decreasing right. So, this B n's are like Russian dolls they are nested decreasing everybody with me just think about it if at least one of a n a n plus 1 a n plus 2 etcetera occurs right that is a bigger set than at least one of a n plus 1 a n plus 2 etcetera occurring right correct. So, I can use continuity of probabilities to write this as probability of agreed this is continuity of probabilities and using the fact that B n's are nested decreasing fine. So, that is equal to limit n going to infinity probability of my B n is after all union i equals n through infinity a i I have just copied what B n is. Now, I can use union bound on that I have a union of events. So, probability of a union is less than or equal to some of the individual probabilities after all I have to get to a sum of probabilities at some point right. So, this is less than or equal to limit n tending to infinity sum over i equals n through infinity probability of a i. So, this is union bound this is continuity of probabilities everybody with me. So, now the proof is almost over reason is I know that the summation this is a converging summation right this converges to something finite. And you know that this guy is the tail sum of a convergent series and as n goes to infinity the tail sum has to go to 0 right you know that from your sequences in series right. So, this has to be equal to 0 right as n goes to infinity this goes to 0. So, I have prove what have I proven I have proven that with probability 1. So, with probability 0 the there is probability 0 that infinitely many a n's will occur which means with probability 1 only finitely many a n's will occur right which means beyond the point a n's will all a n's will fail to occur beyond the certain n naught none of the a n's will occur good. So, this is a very simple proof. So, this is hardly 3 steps with me any questions. So, now we have to prove second Borel Cantelli lemma. Second Borel Cantelli lemma says that it is a partial converse why am I saying it is a partial converse you need independence right it does not say that no matter how this summation is infinite I will always have infinitely many that is not what it is saying right you need independence. You have it is further stipulating independence right the second Borel Cantelli lemma it is a little bit of it requires some algebraic jugglery here. So, I will prove a lemma to prove a lemma. So, the second B C lemma I want to prove another lemma to prove it there we go suppose 0 less than or equal to p i less than or equal to 1 is such that sum over p i equals infinity then product i equals 1 through infinity 1 minus p i equal to 0. So, this statement has nothing to do with probability as such it is just a you are saying that if something if series sums to infinity right series of numbers you have this p i which are between 0 and 1 you can think of them as probabilities, but it is not necessarily the case right it sums to infinity. So, then you have this product is 0. So, the proof of this is again just algebra. So, we have the following. So, we have log. So, it follows from this fact log 1 minus x is always less than or equal to minus x for x in 0 1 right this is something you can prove this is just an identity this is identically true right for all x in 0 1. So, you apply. So, you take logarithm of this. So, let me do that. So, you have log product i equals 1 through infinity 1 minus p i equal to log of limit n tending to infinity product i equals 1 through n 1 minus p i. So, this guy see I want to prove this guy is 0 right. So, I want to I am just taking log because it is a product a log of a product just becomes a summation right. So, this will become. So, this I am writing as a limit. So, now I have less than or equal to log of pi i equals 1 through k 1 minus p i for all k right. So, this can only be bigger right I am only going. So, this is for n bigger and bigger. So, I am multiplying numbers that are less than 1 right. So, if I stop at some point right I will only be bigger right and log is a monotonic function right. So, this is again simple algebra just nothing very deep here. Now, what do I do I have log of all this product which is equal to I can write it as log of a product is sum of the logarithms right. I will have sum over i equals 1 through k log 1 minus p i which is less than or equal to sum over i equals 1 through k minus p i right. This is this relationship is because of this guy right. So, first or note that you just say note that here. So, from there you get this and this is also true for all k. So, taking k to infinity. So, if I take k to infinity what happens to this term yes I know that sum over p i is infinity. So, this summation will go to minus infinity which just means the product will go to 0. So, we have log of all this product 1 minus p i this way will go to minus infinity implying the result right. So, that is just a lemma to prove the lemma and this lemma has nothing to do with probability just algebra right. So, now I want to really prove this Borel Cantelli lemma 2 actually let me keep this part of the board I will prove number 2 here. So, I have to prove. So, in order to prove Borel Cantelli lemma 2 I have to prove probability of a n infinitely often is what 1 right or I can prove that the complement has 0 probability that is also fine right. So, what I will look at is in fact the probability of the complement of this guy. So, I have 1 minus the probability of a n infinitely often is equal to the probability of union n equals 1 through infinity B n complement agreed. I am looking at the probability of the complement a n finitely often essentially and that I am using de Morgan to de Morgan on this this. So, this I will again use union bound sum over n equals 1 through infinity probability of B n complement. Now, I want to prove that this is equal to what I want to prove this is equal to 0. So, in order for this to be 0 I need the only way this can be 0 is each of this B n complements should have 0 probability right. Otherwise it is not happen. So, I want to prove that each of this is 0 and therefore, you are up bounded by 0 which means it is 0 right. So, here I go. So, you have we will show probability of B n complement equal to 0 for all n greater than or equal to 1 indeed fix n and m greater than or equal to n. Then you have probability that intersection i equals n through m a i complement is equal to. So, this is. So, I am taking an intersection of a complements. So, why am I doing that I want to prove that B n complement has 0 probability and B n complement will have intersection a i complement. But, it will it will go from n to infinity, but eventually I will send m to infinity use continuity of probabilities. So, if you look at this a i's are independent events you can prove that if a i's are independent events. Then a i complement are also independent events you have to prove it you do it as homework. So, this you will get this what will happen to this this will product out right this will have pi i equals n through m probability of a complement which is 1 minus probability of a i good. Now, if I send m to infinity what happens. So, if I send m to infinity. So, look at this very carefully if I send m to infinity limit m tending to infinity I will use continuity of probabilities to put the infinity here which will give me probability of B n complement. And then I will get i equals n through infinity 1 minus p of a i. So, what I am saying is thus probability of B n complement is equal to limit m tends to infinity probability of intersection i equals n through n through m a i complement. So, this is by what relation this is because of continuity of probabilities right because B n complement is the intersection n equals i equals n through infinity a i complement. I am writing it as a limit using continuity of probabilities and by this relation I will get this is equal to a product. So, I will put the limit here and right. So, that will become i equals n through infinity I may be skipping one step here 1 minus p of a i. You know this statement of the lemma is that almost surely a n occur infinity of almost surely means. So, this almost surely means with probability 1 w p 1 or a dot s is something that used interchangeably it means that the probability of that event is 1. So, far with me. So, now this I know what this is why because I have see I am going from some n to infinity, but I know that if I some p of a i from n to infinity I will get infinity. So, by that simple algebraic lemma this will be 0 for all n greater than or equal to 1 by the lemma by that earlier algebraic lemma because this p of a i some to infinity right. So, this product will be 0 by the lemma. So, which means for every n greater than or equal to 1 probability of B n complement is 0 right which means that guy will be 0 right. So, from here you can conclude that that is 0 because each of this is 0. So, the summation is 0. So, probability of a n occurring infinitely often is 1 everybody with me. So, I will give an example in a little bit, but first I want to make sure that you understand the proof everybody with me.  So, I will. So, in what remains of this lecture I will give an example to illustrate the first B C lemma second B C lemma. And I will also illustrate that if you throw away independence completely throw away independence from the second lemma and you still have this it does not necessarily mean that infinitely many a n will occur with probability 1. So, it is not a complete converse right first I will do the example. So, do some example. So, the simplest example is. So, you are looking at whether a sum of certain probabilities goes to infinity or is finite right. So, you have to look for some convergence series or non convergence some something that is going to infinity some divergent. So, example see I am going to toss. So, it is like this infinite coin toss model except my probability measure is not going to be what we already studied. So, I am going to toss coin infinitely many times and my sigma algebra is your familiar sigma algebra whatever we did except now the probability measure is not going to be my half the fair coin measure I am going to put something more complicated on it. Let p let a i be the event that the ith toss is heads as usual right we studied this look at this before. And let p be a probability measure on omega f such that probability of a n equal to 1 over n for all n greater than or equal to 1. So, I am taking some probability measure which has the property that the probability of the nth toss turning up head is 1 by n right. So, I will. So, this 1 by n. So, this has the property that summation is infinite right. So, I will later make. So, sum over 1 by n is infinite if I make this 1 by n square it is summation is finite you know right. So, if I want to give the example of the first Borel Cantelli lemma I should probably just give 1 by n square to begin with right. If I keep 1 by n it will be an example for the second lemma. So, let me keep 1 by n square. So, I am not specifying see I have not told you what the measure is on the entire sigma algebra you take whatever measure you want that has this property. I have not see I only specified measures for a n right I have not told you what the measure. So, you have to do the full story right like we did it for the fair coin toss model, but I am saying let p be any probability measure which has this property. You can prove that you can formalize this no problem, but I am all I am saying this. So, let us think about this intuitively I am saying that I have this infinite coin tosses the probability of the first toss being heads is 1 probability of second toss being heads is 1 fourth say third toss being heads is 1 9th and so on. So, it is becoming heads are becoming very very unlikely as you go along right the probability of the 100 toss being heads will only be 100 10000 right is very very unlikely as you go along. So, you have so this is since sum over p of a n is finite actually if you sum n equals 1 through infinity of p of a n you will get pi square over 6 right it does not matter what value it is right it is finite correct. So, sum over n equal to infinity 1 over n square is finite b c lemma b c lemma 1 implies implies that almost surely only finitely many heads will. So, all I am saying this that if your heads are becoming more and more unlikely like 1 by n square. So, in the nth toss the probability of finding heads is only 1 by n square I am saying that there exist an n naught almost surely beyond which no heads will occur you will get only tails beyond n n naught you will get only tails and with probability 1 there exist an n naught such that beyond n naught there is exist only tails that is what this is saying. So, heads will stop occurring all together with probability 1 correct is that clear. So, statement says almost surely only finitely many heads will occur which means there exist with probability 1 there exist an n naught beyond which there will be no heads with probability 1 there will be no heads whatsoever beyond a certain n naught and such an n naught exist with probability 1 yes. So, for any positive yeah. So, for any n. So, for any given n the probability of heads is 1 by n square, but what I am saying is the what the Boral cantile lemma is saying is that there exist some n beyond which you will never see a head with probability 1 right the set of all. So, the set of all and the set of all coin tosses which corresponds to having infinitely many heads will have probability may will have measure 0 the set of all coin tosses in the 0 1 power infinity which correspond to infinitely many heads will have probability 0 that is what this is saying. So, now if you want to tweak it around and make it into an example for b c lemma 2 what you have to do. So, suppose yeah so you have to of course, make this coin tosses independent you have to make a appropriate model in which. So, next suppose p of a n equal to 1 by n and that a n's are independent. So, you have independent coin tosses now. So, in earlier case you do not even need independence you did not need independence at all right now you are saying that these coin tosses are independent and my probabilities are now 1 over n. So, in my 17th toss the probability of getting heads will be 1 by 17. No there exist now with probability 1 there exist an n n naught beyond which none of no heads will occur. That is not what I am saying I am looking at a n infinitely often right I am saying probability of a n infinitely often is 0 you are not looking at probability of a n naught plus 1. So, which is why I am saying this Borel country lemma is very easy to state, but difficult to digest right. So, think about it. So, in this case let me just finish this example. So, you understand the example. So, you have your tossing coins independently and the probability of finding heads in the nth tosses 1 over n. So, here also that heads are becoming more and more unlikely right. So, in the 100th toss the probability of heads is 1 over 100 and probability of tails is 99 over 100. So, it is becoming overwhelmingly likely to see more heads, but according to second BC lemma see since. So, what I am saying is since sum over 1 over n is infinity and the events are independent right BC lemma 2 implies that almost surely infinitely many heads will occur. So, what you are saying is. So, if you will just look at this as n. So, let us say this is n equal to 1 and then you are looking for out. So, if you are looking for out if you are looking at some 100 the probability of finding heads is 1 over 100. If you go to 1000 it is 1 over 1000, but what BC lemma 2 is saying is no matter how far out you go you are guaranteed to find with probability 1 you are guaranteed to find at least 1 head turning up no matter how far out you go. So, although so you may imagine that n is a million the probability of heading getting head is 1 in a million 1 in a million, but I am saying that if you look at million plus 1 blah blah blah the rest of the tail events there is the tail event there will be 1 head popping of somewhere with probability 1 no matter how far out you go you can go to million or billion it is becoming more and more unlikely, but if you look at the entire tail there will be at least 1 head popping off. So, this is a highly non trivial result I want to this is not something that you can easily predict with some elementary probability calculation right. So, if you have 1 by n you get infinitely many heads occurring although it is becoming more and more unlikely, but if you make it 1 over n power 1 plus delta then the series will converge then the heads will stop occurring all together right. So, this 1 over n is this transition point right. So, the probability of heads is not 1 over n, but 1 over n plus n power 1.001 then heads will stop occurring almost surely because the series will converge right. So, I hope this example is clear think about it takes some time to digest the final point I wanted to make is that you cannot completely get away from the independence in the B.C. Lemma 2 for example, if you take you fix any event e whose probability is strictly between 0 and 1 strictly between 0 and 1 and you take all your a n's to be equal to that e right all your a n's are equal to that event e then sum over probability of a n will be definitely infinite right because you are summing something. So, that will be infinite, but still the probability of infinitely many a n's occurring will be simply the probability that e occurs because all the a n's are equal to e right. So, you cannot just throw away this independence, but it is also true that you do not strictly need independence right with independence the B.C. Lemma 2 works, but you can make a slight relaxation on the independence also which is why there are many Borel Cantelli lemmas, but you will only worry about 1 and 2 1 does not require any structure 2 for 2 we have independence you cannot throw away thank you will stop.


Elizabeth. Are Elizabeth. Yes, she is. Yes, she are. Elizabeth Cornwell. Please welcome our Elizabeth Cornwell. You guys having a good time? Before I start my talk, I just wanted to say that this has been a terrific time. Even though it's my fourth time, it feels like I'm a first-hammer because I'm usually working my boss. Some of you may know of him. He's a zoologist in Oxford. I've written a couple of books. Some people have prayed. But anyway, this has been terrific and I'm so appreciative of James Randi and DJ Grothe and the entire JRef staff for the tremendous job they do at this conference and it's wonderful to be with such a great group of people. I also wanted to mention just briefly how impressed I was with Jamie Ian Swiss Talk this morning. It gave me a lot to think about and I hope it gave all of you a lot to think about. And what I really hope is it gives Bill Moore a lot to think about. So anyway, so I'm going to be talking a little about social networks and you may wonder what an evolutionary psychologist knows about networking. I'm sure my web staff is interested in knowing what I know about networks. But I'm hoping I can convince you I know something. So in biology, things really make sense when framed within an evolutionary context. Things like reasons for the mating of the Amazonian milktoad. And if we are out for a drink, I can explain these things too.  So don't get me started unless you really want a conversation about the sex life of Amazonian milktoads. But the secretion of garden eels and why reindeer hooves click. And why male seahorses are always going to be single parents. All these things become transparent, which when we look at it through the Darwinian lens, which is the beauty of Darwin's theory of natural selection. And so when I get a little stressed out, which happens now and again, I tend to go back to reading articles and books that are in the natural sciences, especially in the biological sciences. And it's because it makes kind of sense out of chaos. But there's one species in particular that really is confounding when trying to explain behavior from an evolutionary perspective. And that's us. I hope I have not offended anyone from Minnesota.  We think abstractly. We possess very complicated technology. We have an intelligence that can explore the things from the minutiae of the atom to the great expense of the universe. We understand how all of life is connected. We're all related. Our DNA shows related to every living thing on this planet. We have created medicines and treatments for diseases and genetic disorders that our ancestors thought were caused by demons or sin. Now, all of our accomplishments as a species has been dependent on the evolution of language. But it was... That's how it happened, you know. We finally figured it out. But it was the development of record keeping of writing, which was actually for commercial use. Again, it's the accountants. That we began this long journey to present information technology. And information technology has come a long way from simple record keeping. It's developed in various ways from writing, texting, emails, tweets, and phone. We can also throw in some other forms of media, print media, electronic media, art, literature, music, dance, film, and theater. All these are forms of communication that take advantage of the human intellect and its ability to create meaning and the desire, the desire to be understood. But with the rise of information technology, especially in the last 10, 15 years, it's come at a cost. We lose some important components of communication when we are no longer face to face. Now, in some communications it may not be important, especially communications that make up for the loss of nonverbal transmission by making a pronounced effort to communicate clearly. So for books, for example, a talented author will labor extensively to be understood to make clear his or her meaning. Charles Darwin was one such author. He labored over his writings to clarify his thoughts to his audience. But as communication technology has advanced, there seems to be an inverse relationship on clarity of thought. Using fast communication devices tends toward terse short sentences that can be misinterpreted easily as curt, rude, or disrespectful. Let me expand on that. We live in an environment where the need of transmission has overridden the need to carefully compose our communications. We become impatient if someone does not respond to a text, email, or voicemail within a short amount of time. And we expect ourselves to respond quickly to such communications. Thus we respond with abbreviations, clipped sentences, and symbols. And while it does show the incredible ability of the human mind to adapt to new environments, and it's something that humans are just so incredibly good at, but it's easy to contemplate with the loss of nonverbal communications along with nuance with a decrease in the use of words that the art of communication is compromised. Now please don't take me to mean that I think that social networking is the doom of humanity and insurable end up being comic books. I'm not suggesting anything like that. My only point is that we need to be aware of the limitations of its use, its weaknesses, and that it is prone to misunderstandings. And it can lead to interpretations of aggressiveness at times. Now humans are the most socially complex species on the planet. And it was language that has been an integral part of our social evolution. Our ability to store and pass on information has allowed us to build ever more complex societies, all while pushing the limits of human adaptability. Because our brains are not all that different than those of our ancestors who eked out a living on the African Savannah. But we have most definitely changed the way we live and the way we interact. We are no longer living in small bands of related individuals, but in inconceivably populated cities where we know less than one percent of the people within them. The transition between our hunter-gatherer past and our current environment has not been an easy one. And as it's been said for the most part, nasty, brutish, and short. Now in Steve Pinker's new book, The Better Angels of Our Nature, which Michael Schirmer touched on yesterday and I hope you heard his talk. It was excellent. Pinker explores the process by which humans have become less violent, more tolerant, and caring. In other words, just more humane. And he also explores and expands on the concepts first proposed by the German sociologist Norbert Elias called the Civilization Process.  This was all working outward from a nucleus of court etiquette. And Michael, wherever you are, I do appreciate the fact that you went over all those disgusting bodily habits, so I don't have to. Now in his book, Pinker discusses not only how the civilizing process progressed across the world, but also how in certain environments such as the emerging Western US territories, there was a regression back toward a more violent, undisciplined blood honor and vigilante lifestyle. All fitting with the thesis that as society implements and enforces standards of behavior, we are more able to live together in harmony. And when for reasons such as a new frontier where social protocol is no longer in effect, we humans tend to revert back to less civility. We no longer worry about being shamed or ostracized by society or risking our loss of social standing. And that for humans, the loss of social standings is a tremendous loss. In other words, without punishment of society for bad behavior, without the repugnance for bad behavior, we regress toward a more base state. Now I want to bring together what may have seemed like two disparate concepts, but they really are interconnected. So at the beginning of the talk, I mentioned that communications rely on signals other than words. Eye contact, facial expressions, body language, tone and inflection, they all convey meaning. And often when we rely on these signals to make certain, we rely on these signals to make certain that we're understood. So for example, when we say we're sorry, if the words don't match our nonverbal signals like, yeah, I'm sorry. Then our words do sort of fall flat. And instead of an apology deescalating a situation, it antagonizes it instead. So when we communicate using electronic means such as emails, blogs, texts and tweets, et cetera, we are relying solely on words to convey complex meaning. Yet with such technology, we tend to invite us to use fewer words, shorter sentences, and yet we still expect our audience, the receiving end of our messages, to get exactly what we're trying to say. Well of course, misunderstandings are going to happen. Now let's add to the mix the idea that the internet is a new territory where societal pressures are few. Especially since individuals can hide under false names, they can change their names, they can remain anonymous. Thereby circumventing the social punishment for bad behavior. Additionally, without face-to-face interactions, we lose our sense of empathy. And we also lose our ability to quickly disabuse our audience of an obvious misunderstanding. Now losing the lack of empathy is important because when we're talking to someone face-to-face and we see that they're in distress, most of us know to back off. Most of us are not going to keep up with threatening that person or making that person feel badly. So losing that is something we need to be aware of. So what we end up with is sort of a wild west environment, violence in the form of threats, bullying, and vigilante posse's bubble up across blogs and tweets and other form of social networking. And this phenomenon can be understood when we apply Elias's theory of the civilizing process to the internet. Now cyberbullying has a real dark reality to it. With young people such as Megan Meyer and Jamie Roadmire giving up all hope after relentless bullying and taking their own precious lives to finally end their torment. And in a study of young people by Samir Hinduja, I hope I didn't slaughter that, and Justin Patchen, they found that 20% of respondents reported seriously thinking about attempting suicide. All forms of bullying were significantly associated with increases in suicidal ideation. Cyberbullying victims were almost twice as likely to have attempted suicide compared to youths who had not experienced cyberbullying. And this is interesting. Those who commit bullying are also at higher risk of suicide. Now as the issue of cyberbullying comes into the public sphere, it's being discussed and debated concerning what to do. The awareness too, although we can't confirm this, it's too early to confirm with any kind of data, but it possibly could facilitate a downward trend because of social disapproval. But also states are also imposing anti-bullying legislation, at least in terms of children, in response to some of these tragic outcomes. But cyberbullying doesn't stop at the end of adolescence, and it doesn't take long to find examples of flaming, trolling, threats of violence, or even organized attacks across blogs and tweets in the adult world. Now the root causes of uncivilized behaviors are in part the same as we see in adolescent cyberbullying. Narcissistic tendencies, low self-esteem, false self-esteem, imagination of power, these are all reflected in the personality of the bully in his or her henchmen. Now there are relatively few studies on adult cyberbullying or issues of civility on the internet as it's pretty recent phenomenon, but the few that do exist suggest that there's a strong tendency on hotly debated issues, such as the example of politics, things like aggressiveness, certainty, angry assertions, insults, and the attempt to humiliate opponents. Is any of this hitting a chord? So now the CDC has initiated more research in the area and labeled the problem as electronic aggression, giving it a broader name. And for the most part, again, studies focus on children and adolescents. But really it would be a mistake to end it there. Now psychologists have had little time to develop comprehensive theories on electronic aggression, but certainly the decades of research on bullying in general provide some sound-building blocks. But I want to propose that the internet offers a unique environment that perhaps exacerbates the problems, especially for individuals who are prone to bullying or prone to being what we call henchmen, which are the kind of friends of bullies that help the bully along. There is evidence of a positive correlation between narcissistic personality disorder, which is called NPD, and electronic aggression.  And by the people who they found had tended toward narcissistic personality issues, they were just counting the number of friends they had on Facebook, or the number of comments they had on their blogs as being measuring their success, measuring their social status, measuring who they are as an individual and their contributions. And then when faced with any criticisms or non-support, the narcissistic person can react angrily and aggressively. So in other words, the internet, unlike the real world, can provide, more than sure, easily provide a false sense of importance and an overestimate of contributions to society, as well as bolstering the false sense of self-esteem. And in some cases, it may even cause kind of what we call acquired NPD, which we might see with brand new stars that make their way. They, you know, kind of not used, not accustomed to the feign to become narcissistic. It's acquired and not necessarily something that they, not a genetic cause. But when, so when, narcissists, when their self-esteem is threatened, the individual lashes out and goes on the attack. And such attacks will include threats of harm, vilifications, especially, of anyone who kind of commits the offense of either ignoring them or criticizing them. The other thing that the internet does that is unique is that it brings people of various abilities, expertise, education and backgrounds together on a single topic. Now, the narcissist will tend to identify him or herself as part of the high status group, the people who are very knowledgeable on the topic, the people who have the education or the expertise in a particular area. Yet, at the same time, the narcissist will feel threatened by these high status individuals because the high status individual, you know, if they were to meet face to face, they'd be kind of found out, right? So the narcissist actually does understand that they, their, their self is, their, they have kind of a false self-esteem there that they don't really have what they wish or tried to project that they have in terms of, of talent or education or knowledge. So the narcissist will use electronic aggression to act out against those people in higher status and, and not really through any kind of valid discussion but by personal attacks. Now, most of us do not engage in such bullying. We have better awareness, empathy, control and we engage in contemplation as to how our words might affect, aggravate, hurt an individual. And just as we check, we check our words in cyberspace just as we would check our words in our personal space and our public space, we, we care about people and that's, that's generally the majority of people but it doesn't take but a few to, to kind of ignite some of, you know, electronic aggression. So social networks, I mean they're still nascent and reflect, as I said, a bit of the wild west but I suggest as it evolves, it will go through a civilizing process. Now for example, in the 70s, some of you remember the 70s, I certainly don't. Sorry, I'm just taking this from my history book. It would have seemed rude to ask someone not to smoke in your own home and even if you were a non-smoker, some, it was just common if people smoked in your home but today it's considered a common courtesy for smokers to step outside if they must smoke although obviously not in casinos in Las Vegas but those people who don't smoke now feel it is within their right to keep their home smoke free and no reasonable person would accuse the homeowner of denying someone his or her freedom by asking them to step outside to smoke. Well it's also the same with if somebody came to your party and they were obnoxious and aggravating your other party guests and just being a pain, the host would have a right to ask that guest to leave and no one would accuse the host of denying that person their freedom of speech because they asked them to leave the party. So I think you know where I'm going with this. So how do we create a more civilized internet, a more civilized social network? Well I'm not saying that we have the answer but at RDF we do moderate our discussions and comments and we do take the view that RDNet is our home and we want people to feel comfortable in expressing their opinions and so we do our best to keep out trolls and individuals who resort to less than reasonable discussion and we don't just constantly look for comments, nobody has time for that. It's our, the people that come to our site that alert us to people being obnoxious, people being trolls, people causing trouble and attacking others for making personal attacks. So because of this, and we did have a few complaints, people said oh freedom of speech and the fact is we don't consider it heavy-handed censorship and of course we're not the US government, we're not bound by constitutional law, we are simply maintaining an atmosphere on our website that we feel is civil. We don't go through approval of postings, there's no queue in terms of our postings. It's just simply monitoring content in our site and because we've done this over time, we no longer have to do quite as much as we called it smiting. That was always fun. Shall we smite him? Yeah, he's been smote. People come to our site for opens, so because of that we don't have to do a whole lot of that and so people do come to our website expecting open civil discussions and the fact is that we don't have a big problem with bullies and aggressive behavior but we do invite well thought out and valid criticisms. I mean people have discussions and they disagree and it's quite civil. It's like what you would do probably at the bar here, you're sitting and talking, you can disagree about things but you're not going to start saying well I hope you're found burning in hell or something, whatever. I'm sure that's not what we would say but you get the point. So social networking is a powerful and extraordinary change in our ability to communicate and I think it's reasonable to say that it equates an importance with the printing press because it has changed the world and I really do think it has changed the world for the better and combined with access to what seems like really unlimited information via the internet, although of course we've heard a lot about how a lot of the information on the internet is not all that reliable but social networking does grant us an opportunity to explore well beyond anything we could have imagined. And in the lifetimes of most of the people at this conference we've seen changes in how we interact with one another that are really quite astounding. And while social networks are still in their awkward adolescent stage struggling with what it will become in recognizing its limitations, issues such as cyberbullying and uncivilized behavior are just growing pains. I think it will be resolved and those who engage in poor social behavior will be marginalized in social networking just as they're marginalized in real life if you know, face to face, I'll put it that way because internet is real life, isn't it? And people are also understanding that the internet, everything we do on the internet our comments or posts or blogs, they kind of stay with us for a really long time and as we come to terms with the fact that our past is not particularly easy to lose, we begin to self adjust our behavior and while we can remain anonymous which gives us maybe some protection for admonishment but I don't think you can guarantee that it won't come back to haunt us so just keep in mind this age old adage that the only difference between love and blog posts is that blog posts last forever. So in closing the majority of people again are responsible, they're kind, they're thoughtful when they use technology to communicate and I think we've all had experiences where there have been misunderstandings with text messages and things and we allow for we have allowances for people and I want to go back to what Jamie said this morning of the importance to understand we're all human.   We've all said something that we regret we've all said something that we kind of wish would just disappear into the fog of time and most, and before now that usually is what happened. Unless you happen to be someone that the press followed, the things we said sort of disappeared. But now people can and do judge an individual by one post, one tweet, one article. We make entire judgments on people based on one thing that they did and none of us would want that.  And I think Jamie's point of being humane, as skeptics we don't mean we can't be humane, that we can't recognize that we're all fallible, that we're all, you know, we're all struggling. We all just try to make it through this world the best we can and do the best we can. And I think we need to have allowances for one another. And I'm hoping that the internet will reflect this and I'm hoping that this community in particular can lead that charge. And I think we can. So I just want to say thank you again. And I really do think the issues of uncivilized behavior will dissipate. And I just want to say please network wisely and be human. Thank you.


Bye, good morning. Thanks for coming. Some of you went early enough and I've got a bunch of people standing at the back, I'm sorry. I hope that you can see the slides. If anyone would rather have the slides on their own device, either to add some notes, or to make them easier to read, they're already online. I've just tweeted them from my Twitter account. If you look at, I'm also Lorna Jane on SpeakerDeck. So if you'd rather grab those slides, that's where they are, please help yourselves. My name's Lorna. I'm a Developer Advocate with IBM. Ac oedd hyn yn dgylcheddyn nhw'n dwy Lord krath o'r cyd-fyrdd o yndyn Lly mae 300 o arden nhw'n credu iawn. Rwy'n gweithio'r rhai ffost ar leion fy mod iddyn nhw... ...reulio'r cyd-fyrdd o'r Llyfrgell hwn i ddechrau a mwyafhau ar y dyn ni... ...bi'n cyd-fyrdd a rydyn nhw'n ddechrau i ddechrau. anything that makes things better for developers using IBM Cloud, that's what I do. My specialist topics are mostly open sourced databases, open sourced scripting languages and of course our cloud. Today I'm going to be speaking about web hooks and this might lead you to ask What is a web hook? A web hook is an HTTP host request I'm totally not going to do this, but I would feel entirely justified if I ended my talk now. I think the pub's probably open if anyone. I'm going to give you some more information, but hold on to this. If you know about post requests, then you're already qualified to work with webhooks. This is everything that you need to know. You've also already seen them out and about, even if you don't know this is what they're called. You have seen webhooks in the wild. They're what power your Slack integrations. If you have your GitHub or GitLab projects chatting into channel, do not let me give the chat ops talk now, we'll be here all day. The idea that we can integrate two systems, you do something in one place, you push the GitHub and that event causes something to happen in the conversation. I love chat ops, I love having notifications in the channel in context with the conversation that the developers are having. If you are looking to integrate a system that doesn't have a click here to add this integration on Slack, you just choose incoming webhook and you can accept any kind of notification into your Slack channel. On GitHub, we have it with the builds. This is a Travis CI build, somebody owned a pull request and the build failed. We know not to merge it, but that build was run on Travis in response to new commits on GitHub and that integration is also a webhook. Webhooks are all over the place. I use them quite a lot with Zapier which is an amazing platform. Do not Google this now, listen to my talk first, right? Because it's too interesting. But if you haven't played with Zapier, have a look. It's a brilliant way of integrating lots of different events. Something happens on Dropbox, take a copy of it, upload it here. When you tweet this, do that, add it to a Google Doc. Somebody mentions you, put it over here. So there's lots and lots of ways that we can use these webhooks to exchange data between systems, to allow systems to react to one another. Exchanging data between systems over HTTP and you're thinking, I think she's trying to sell us APIs with a different name. Let's compare those two ideas. How APIs work. The client asks the server, please may I have some data? And the server says, here's your data. Unless there isn't any, in which case it kind of says, nope. In a friendly way. Compare this with webhooks. The same conversation takes place, but the server starts the conversation. The server says, hey client, I have some data for you. And the client says, thanks, smiley. In HTTP we spell this like 200 okay. But you can think of it as thanks, smiley. So that's a webhook. The server starts the conversation. The server has to know where the clients are that would want this data. So there's a little bit of preamble. We have to set this up in advance. Like many excellent technical concepts, these things seem pretty much equivalent until you think about how they're going to work in practice, under load or over time. So let's have a look at this. And for this I flipped the diagram round. Time is going left to right with the client at the top and the server at the bottom. So with an API model we're going to be polling. The client asks the server for some data and may or may not get some. And you can see this quite chattery set of traffic going on here and only one piece of data getting delivered the second conversation along. Compare this with the webhooks. When there's some data we send the data. We don't need to talk about it the rest of the time. We're not doing an ongoing, anything? No. Anything? No. Webhooks are a bit more efficient. Isn't a coincidence that it's GitHub that I keep using as an example? Can you think about how many repositories you have on your GitHub account or maybe your organization's GitHub account? Now think about what the web traffic would look like if your CI servers were pinging every one of those repos every minute to look for changes. And you'd have to wait up to 60 seconds for the build to even get in the queue or the message to come in the channel and to us that's outrageous. Who wants to wait 60 seconds? What is this? An overnight batch CSV import. We're accustomed to this reactive programming that the on-demand webhooks give us. I wanted to touch a little bit on the data that we put into the webhook payloads and this brilliant idea that I would show you a real example. Webhook payloads are quite verbose. There are 111 more lines not shown here. I experimented with a smaller font but it was basically nonsense. Right? Verbose is kinder where it's at with webhooks. But you need to take into consideration when you're designing payloads of your own. We often work with this kind of loose spec JSON nested data and we try and include the majority of things that a user is going to need. Here you can see that we've got the previous commit ref, the new commit ref, some information about what happened here, a link to comparison, and then inside the commits array there'll be information with the commit ID, the committer ID, the timestamp, the email, the message for every commit. All the details of the repository, all the links to the contributors and branches and pull requests and everything of that repository. And the same for the pusher and the sender which are normally the same but not always. So there's a lot of stuff in here and I think it's a fairly typical webhook payload idea. When you're designing webhook payloads it's exactly, it feels very machine oriented but we exactly need to begin from a user story. Why would a user subscribe to this webhook event? What is it they're going to do next? What reaction are they having? Because if you send just the commit references in an array and let's say you're the Linux kernel project and there are tens of thousands of people hundreds of thousands of people subscribed to that event you send out the webhook from your wonderfully scalable system which I'm going to show you how to build and then every single one of those consumers makes an API call for each commit reference to get the name of the committer and the commit message and the other information. And this is what I like to call a DIY thundering herd problem, right? You made this. You sent out an incomplete event notification and caused all of those incoming API requests so be careful. Try to think about what people are likely to do next. Feel free to go minimal with your payload but then look at which API calls get hit next and start adding data in. It should be safe to add data into your payload that shouldn't break other people's code. We, over years of working with APIs I mean I've been building APIs long enough that we considered not only the cost of the user's data package and the speed of the network but also whether they would have a chip in their phone and powerful enough to decode this format. A lot of them didn't have good string manipulation chips. I'm going back a while. And for APIs, for mobile-facing stuff, even for client web-facing stuff we tend to try to keep things quite small. We're very conscious of packet size. Webhooks are, for the most part, server-to-server. They're two server-side applications communicating with each other, however many, all communicating with each other. You can assume that these are powerful machines on a decent network. So verbose is actually okay depending on your use case. Keep the data format simple. I saw a project a while ago which had this absolute... I mean it was glorious. It was beautiful, validated schemers and whatever. No third party could integrate with it because it was just too complicated and it wasn't well-supported enough across different programming languages. Seriously, JSON, BSAM, Apache Thrift, some sort of serialized format, just keep it super simple and very standard and then everyone can integrate with you. Please don't forget that we know how to secure HTTP traffic. We've been doing this web thing for a little while. So don't forget how to do that and don't invent anything new. We know how to secure this. Think about what your attack vectors are. I think this is a massive issue in our industry right now, particularly with the advent of the Internet of Things where security seems to be completely optional in many cases. So don't go there. Think about what can happen. If you are receiving webhooks, you've got an open endpoint, anybody could post to that. What could that do if a lot of requests came in? If you're publishing webhooks, what if a lot of people subscribed to that? How much can your system scale? How much potentially wasted resource do you want on that? Do you need to register everybody? Think about what those things can do because this is at scale. So it's not a person making a web request. It's a botnet taking all of your platforms out or at least running up your hosting bills. Always use SSL. This is non-negotiable. If you are doing webhooks and you are not using HTTPS, you are doing it wrong. There are very few situations where I tell you you are doing it wrong. Not using SSL on production webhooks, if you register for a GitHub webhook, you'll notice that they offer the shared secret option. If you set a secret, they use that to create a hash that you can then check on your side when the packet arrives. Everything you know about HTTP is good. Hopefully I'm not teaching anyone anything new. Okay. The bunnies are here to remind me to slow down and just take a break between sections. I don't blow your minds completely. I mean, I'm not promising I won't, but... I'm going to show you how to publish webhooks from your own PHP application. Before we start, let's talk about why you might want to do that. Please just don't go and publish webhooks for no reason. There are some very clear use cases. The first one has to be the GitHub continuous integration problem, right? Something pulls your API loads and mostly gets no data. Brilliant, move it to a webhook right now. Or at least offer it. Maybe not everyone knows how to handle those webhooks. Not all of your clients want that. But if you have an API, you have a lot of polling, then yes, I would definitely recommend it. If it's common for another application to react to changes in your application. Now I'm saying application like this is yours and this is going to be like some other third party somewhere else in the world. I am sure that a lot of you are moving to a more modern microservices, componentised architecture. One application and another application could be components within the same organisation. This is the most common use of webhooks I see. Internal integration. Sending notifications between parts of your own system. Those parts might be owned by other people. So the other team might own that component, you own this component and you just agree on how you integrate. And I see both webhooks but also message queues in use here. I also see webhooks a lot for notifications. So especially if you're using an external or third party library for push notifications to devices, that kind of thing, then that's a really good use case as well for webhooks or even just moving your own notification stuff out into a separate component where books can really help with that as well. So with that in mind, I have built you an example application. I tried to keep it quite simple and it is a retro guest book. So once upon a time, quite a long time ago, was probably if you were online before the year 2000, we all had websites and these websites had guest books on them. I'm conscious not all of you were online before the year 2000, so I'm just going to explain this to you and we'll skate over how old I am. And the idea of the guest book is exactly like you see in a nice holiday cottage or a hotel where you write your name or where you're from and how much you liked the place. You always write something nice. That is exactly what the internet was like in 1999 because we had these guest books on our website, it's like early dynamic webpages and there's lots of people laughing at me in the audience. And without registering any users, without any moderation on the comment content at all, people could write their name and write what they liked about your website and we displayed those things on our websites. That was a real thing. Lots of people just shaking their heads at me. I know, I know, but genuinely it was a real thing. Ask me about webbrings in the bar, it will blow your mind. Okay, so this example application is a guest book, so it allows us to write our name and leave a comment. It allows us to see those comments that have already been stored and because we're really cutting edge with our guest book, it also sends webbooks so you can register to get notifications of a new comment. If you just can't wait to check the database later, you can get a webbook notification of any new comment on your guest book. It looks like this. The reason it looks like a developer made it is because she did. It's got CSS, what do you want from me? I'm an API developer for a reason. Okay. The process when you fill in the form looks something like this. First we validate the data. Then we write the data to the database. Then we normally return a response to the user. But we're going to deal with webhooks. We're going to send the webhooks to the subscribers before we return the response to the user. There are a few ways we might do this. Some of them make more impact on how long the user has to wait than others. Option one for this Turquoise Circle is simply to look up the list of webhooks and send each webhook in turn. If there's 10,000 people registered, the user is going to wait a really long time to see their page. Okay. We could probably improve on that. Let's use a queue. A queue is ideal for asynchronous processing. Don't let me give a whole rabbit MQ talk now. I'm determined to get you to the front of the lunch queue. Okay. So, we have a queue. So what we do is we take the new comment that was made. We take that data. We look up a list of webhooks and we just stick all that data in the queue, fire and forget, and we return the response to the user. Why am I looking up the webhooks from the web page? We could do that later. I like to look up the list of subscribers here because the website component already has access to the database. It's already reading and writing to the database. If every single part of your system writes to the database or reads from the database, you've just created some... That's not microservices. That's some kind of almighty mess. I know a lot of organisations that have converted to microservices and coincidentally, their DBA resigned. Right. This is what happens. So we need to be really careful about our data hygiene. So I am going to do all the database work up top, put it all on the queue. I don't need to look anything else up after this point. So this is all independent. And then, yeah, we'll write a worker that takes the message off the queue and sends those hooks in a loop. Awesome. I just want to jump in with some PHP code. This is how you write to a queue. This is all on GitHub. You can see the full version where I just ripped out a load of... I think you all know how to write to databases. I took that bit out so it would fit on the slide. So first of all, we sanitise the incoming data from the form that you saw. We save the data to the database. We pick up a list of web hooks. We assemble the dates. We connect to Rabbit. And then we just create a new message and publish it to the queue. So this is all the code you need to write to Rabbit MQ. Feel confident you're all going to handle this. If you're using Rabbit MQs, go for it. It's really not that hard. I'm using Rabbit MQ here. We have it on IBM Cloud. That's not the only reason. I actually love Rabbit MQ. It's not really a hardship, but it's like, oh, I have to use Rabbit. How terrible. But if you're using Beanstalk D, I have known and loved. I've used Gearman with PHP as well, bit further back. All of that stuff is good. I have that in your stack already. So that thing really, I'm not hiding anything complicated from you here. So we could do this. Website puts messages on the queue and the worker just loops and sends. This is kind of tedious. And if something goes wrong partway through, we don't really know where we got up to. So at the risk of delivering a Rabbit MQ lecture, I think you're geeks and you might be interested. Here's how I really do it. So I do exactly the same. I put the comment data list of webhooks onto a message. The first worker picks that up and puts one new message into a different queue for each webhook we need to send. So one endpoint and the message data into each one. Those jobs that go in the second queue are now independent. This is what distributes systems are made of. They do not have any external dependencies. They do not need to make any network calls. They do not need to look up anything about the database. We just have a worker that we can now scale this horizontally as much as we need to because every job is independent. And this is why I do it this way. Webhooks, because you're holding the connection open, can be a real difficult performance issue. If you've worked with the Slack integrations, you don't respond within three seconds, they close the connection. This is because otherwise they run out of web server, holding connections open, waiting for you. So I'm going to talk a little bit more about receiving webhooks in a bit. But this is why I do it this way.  Obviously I'm hoping all of you will write terribly successful applications and therefore you'll have to scale up loads because you'll be really successful. So, this is what we've got. The website puts things in the queue. The first worker puts more things one per end point into the notification queue. We have a bunch of workers actually sending those webhooks, which is sort of relatedly slower. I am going to attempt to demo that guest book and show you around how those moving parts actually move and how you would do this as a developer. For my end points I'm going to use a tool called Request Bin. This is a free tool, it's hosted by Runscope so if you find Request Bin doesn't do what you need you'll find Runscope does do what you need but Runscope support Request Bin it's also an open source project so if you're sat close enough to one of the screens you can see I'm actually running it on a VM it's just Python and I think it has a salary dependency and I use this loads if I'm not sure if I'm sending the right web format or anything just put this in as your end point and then inspect it you'll see an example. Let's see if I can run a video and talk at the same time it could be a challenge. First of all I would like to introduce you to the Rabbit MQ management console this is just a plugin for Rabbit it gives you a web interface at the top you'll see how many messages are in the queue all the queues and down here you'll see things being published to the queue delivered acknowledged we'll see those graphs changing as we go through so here we are with Rabbit MQ and the first thing we need to do is set up these end points with Request Bin so this is what Request Bin looks like click the big green I'd like a new Request Bin button and copy the URL here's the guest book so we will register our webhook end point with the guest book so that new comments will send notifications to that end point so here's an end point this isn't all that interesting unless you have more than one end point so I'm just going to do that again with Request Bin and register a second URL with the guest book so that we you'll see that we go from one message to two messages all the workers on this system are currently stopped if they weren't you wouldn't see anything on the Rabbit MQ admin console because we're like sending a web request it's quite quick I've definitely had this problem before when developing with any kind of queues and workers set up I would very strongly recommend that you regularly stop all your workers while you're developing and testing the system because that shows you what happens when the queues are building up or the workers are stalled for any reason so you should see what happens if just the queues are quite long and it's slow because on dev you never see that you don't see it until load testing but you can kind of preempt it I had one where I could reliably do the image processing on a new registration before we loaded the welcome page except one day I broke my workers and I realised that if it wasn't there it was the ugliest error ever and we put in a placeholder image which we never saw forgot about it we were soft live and then a famous footballer tweeted a link to it lots of people registered strangely enough and the image processing queue fell over quite quickly but it all just kept on working users had an experience that showed them some sort of placeholder image and our workers eventually caught up overnight and we ran out of inodes anyway wow that was a tangent right let's add a comment so remember this is a guest book so we're going to write something nice a bit like you're going to do in your joined-in feedback later so we save a comment and we check out the RabbitMQ admin console oh yeah look a single message has arrived we've added one comment, we're in the first queue now I'll start the workers so this is just the first worker and if you have a look at what happens here in the bottom graph I've had one message acknowledged and two messages published because we took the list of webhooks list, there's two of them and our comment data and turned it into two messages, these are independent if I now start the other worker to process the second queue that's why I've got them running under different system djobs here it is let's start that service and check back with RabbitMQ I've got two messages acknowledged and nothing in the queue we can also go and check out request bin because request bin is where we'll have received our webhooks it doesn't scale up all that well so I'm not sure if you can read this but it shows an incoming post request all the headers that were sent this can be really useful for diagnostics if you need to, you can see everything that came in the content type and here's the actual content which is the comment of my session coming in there and the same if I refresh the other request bin as well another bunny? I'm really glad I put these bunnies in also kittens are overrated my team saw this talk rehearsal and they said it needs more cats needs more cats and I was a bit like it's all about the function you need the thing to perform rather than what they look like so thanks bunnies you're helping me here so what you've seen there is how in a PHP application we would add messages to a queue and then process those messages there's a lot of moving parts there if you're accustomed to just browser sends request, web server sends response there's a lot moving here but I'm hoping that I'm showing you around alright let's look at the other side of this now I think this part is the most important part of this talk I'm not sure that every application has a use case for publishing webhooks just depending on what you're doing may not lend itself really well but I think receiving webhooks integrating with other people's applications whether it's in your actual application or in your bot or other internal tools I think as developers this is something we can all work with so if I lost you already then please tune back in I promise to be less scary just remember it's just a post request it's a weird setup because it's kind of like a backwards API if you're building an API then you are the server and people ask you for things and the post request comes this way whereas often when you're receiving webhooks you're kind of the client but the HTTP traffic comes in the same way PHP is designed to solve the web problem it is ideal perfect for these kinds of applications some things I'd really like to just kind of flag or recommend to you is to think hard about what needs to be done immediately when the webhook arrives and what can be done asynchronously a lot of the time this doesn't well it's a webhook it's not really real time anyway a lot of the time it doesn't need to be instant and if you are doing processing as the webhook arrives then you're holding your web connection open and this way lies madness holding open web connection incoming connections is where the hockey stick graph comes from because then everything's waiting and everything's waiting and everything gets slower all goes wrong so if you can and this depends on your application just accept the data store it, make sure you've got it and then send back the acknowledgement I already remember 200 okay smiley I already mentioned that Slack have rules about how quickly you need to respond when you do this right so you need to there isn't time for you to bootstrap an enormous full stack PHP framework and check that all the incoming data is valid and the accounts are active and then I used to work on a smart energy system and it recalculated the monthly running totals every time a reading came in well the readings came in every 5 minutes but we had a 48 hour lag on processing them because we were constantly recalculating the running totals right so really think about what you're doing here if you can just store it and process it later you've all worked with systems that do this you've integrated with PayPal then you get that that callback later so that you forward your user to PayPal they get forwarded back to you and then you get the notification to say yes the payment went through right so that's an out of band notification coming back to you you can do that with webhooks try not to validate data try not to hang around try to just accept it and log the incoming and the body of the data in full always just log the whole thing I have been increasingly moving this kind of functionality to a serverless end point one of the reasons that I like to store immediately is just to try to protect myself against the very bursty nature of internet traffic in general webhooks in particular seems to be the stuff happening and there are hooks everywhere or it's quite quiet with that smart energy project they used to instrument a whole block of lats and then turn it on all at once every device in the building would phone home the server would fall over so look out for that look out for being able to accept all of that data and process it even if it lags by a few seconds most applications it's fine let's talk about serverless I'll try not to talk too much about serverless the serverless technology and I'm just going to try and introduce it I know some of you haven't used it the idea behind I love the name serverless this is nonsense it's right up there with no ops no ops I might not need to do any ops I'm a developer it's best if I do not do ops but somebody did the best ops you've ever seen and calling it no ops seems a bit rubbish really serverless is the same they're really awesome excellent servers and what happens is you write just a function and I'm about to show you an example and you don't worry about the operating system the framework you need to worry about your language dependencies but essentially you just write a function and you deploy just the function it gets containerised for you and you just say when this happens run my function you can run a command line, make it run it's very common and this is what we'll see in this example to hook it up with like an incoming HTTP request when a request comes to this endpoint run my function it might be when there's a change on that database run my function every five minutes run my function when this value of this feed crosses this particular boundary run my function you just set up the function and what's beautiful about this is it's incredibly simple it's much easier than any actual whole framework PHP it's so small it's like writing really small command line apps but you just run them in the cloud it's pay as you go if you deploy this and nobody uses it it doesn't cost you anything there's no capacity planning there's no please sir may I have another server it just runs when it runs and you can keep an eye on it all of the platforms have free tiers so for prototyping or low traffic sites you're never going to pay for it anyway if the opposite is true and you get a lot of triggers causing your function to run then it just scales up horizontally when you turn on the building of sensors and all those devices phone home at once we'll just run some more of those functions and handle that load so again you need to think about horizontally scalable systems and how you can keep each of those pieces of work as independent as possible you've probably heard of Amazon Lambda obviously here comes the IBM cloud they pay me and my hosting bills there's nothing to not like about this IBM cloud has IBM cloud functions it's actually a hosted version of an open source project called Apache open whisk so you can develop with that locally or an open whisk on your own hosting anyway or we have a hosted version that I use and like Apache open whisk and I think some of the other serverless providers but I'm not sure supports PHP out the box so you don't need to dockerize it or whatever to work around it supports PHP out the box that implementation was done by Rob Allen who I can't embarrass because he's on the stage upstairs so he's not here, me to point at so we have PHP running on our platform so serverless PHP, yeah that's a thing and it lends itself to serverless because PHP is pretty simple it reads from top to bottom it's great, works well with incoming web requests it's a web language if you want to use another platform I'm not sure but I suspect in a room full of PHP developers that maybe some of you know some JavaScript maybe and Node.js is supported on all of the platforms and typically you'll find yourself reading the Node.js documentation on all the platforms regardless of which language you're using so that's serverless you write a function, you deploy the function, you say when it should run so here's my function it's written in PHP a little bit of white space crime to fit it on the slide not too much, sorry about the closing bracket really couldn't fit it on so you write a function and it should be called main and that function accepts one parameter, everyone's still with me okay that function accepts one parameter and it's called params, it can be called whatever you like and here is all the incoming data so if you've set variables when you deployed your function like environment variable style then you'll find those here if there are variables that you set when you called the function then you'll find those here if you can optionally set it up to pass incoming post variables or pass your JSON body and extract those variables as well I've not done that because it makes me a bit register globals frightened itchy online too I'm accessing that parameters variable to pull out the cloud and URL you'll see that being set in a demo in a minute and then I'm manually decoding the body so to get the body just as it was it comes in base 64 encoded so you can just decode it and then mines JSON you've just seen my webhook this code is going to receive the webhook that you just saw me publish so I'm just JSON decoding it and notice that this is a very optimistic version everything's fine we successfully decode everything there's no problems with the base 64 encoding it's valid JSON every time there are no error conditions this is like totally optimistic developer advocate doesn't run on production code so then we store it and we send the response so here I'm writing to CouchDB I've recently published a new PHP CouchDB library so if you're working with PHP and CouchDB please try it and then tell me what you'd like done differently because it's new but it turned my 10 lines of code into 3 so I am using it because I like it that's why I made it and what we do here is we connect to CouchDB we say which database we'd like to use it's called incoming it's where I store my incoming webhook data we set up some metadata to record when we received it and set the status to be new if you are just going to come back and loop through the data that's come in and look at which hasn't been processed yet then the status field's quite useful I'm using CouchDB so realistically I would be watching the changes feed but for an ordinary database you probably would want to come back and look at it like that and then just create the record again and return thanks with a smiley on line 11 because that's how we do that's how we do webhooks we send back that 200 ok and I'm sending back the smiley right so let me show you this as it happens because I want to give you a better concept of again how the developer experience is for that so that would be this one here it is so in this directory I have some files none of this should look alarming you all use composer yes we've got deploy.sh that's my hacky script to I just edited my php file here is what I'm going to run I'm going to type those commands and walk through them with you here I've got a git ignore file because I've got a vendor file hook.zip is what we're going to create index.php is where the code actually lives where the function lives and I'll be our entry point it needs to be at the root of the zip file that we're about to make log me.sh don't think he's under source control but if you look at my blog it's to work with openwisk you can say show me the last activations the last functions that ran and then you can do give me the logs from this activation so this is a script that does one of those and greps it, cuts it, puts it through xargs and just shows me the most reason it's a little hacky script so here's my code I'm going to zip it and then I'm going to deploy it and the reason that I'm zipping it is because I'm using that phpcouchdb library it's currently I'm about to fix this currently not available by default on openwisk but if you have any composer dependencies guzzles there by default that covers a lot of use cases if you have any dependencies then you can just use composer and then zip it like this so I'm using zip with dash r because I'm going to recurse down into the vendor directory you probably want to use dash q here to avoid the insane output that you're about to see and into hook.zip I'm putting index.php that's where my function is and I'm putting the vendor folder because I need those dependencies as well and I'm including the auto loader so there's the zip file created next we'll deploy this function so here's a bunch of gobbledygook let's work through it so bx the ibmcloud used to be called bluemix so its command is still called bluemix or bx for short then I'm working with openwisk so it's bluemix openwisk and I'm going to create an action I know that word doesn't say create but openwisk if it doesn't exist and you try to update it so you can write update in all your scripts and it will always work I love this, just seems super friendly so we're going to update an action this is the name of the action guestbook comment when there's a guestbook comment it's going to hit this end point I've called it guestbook comment it is a PHP action I need to specify the kind when I upload a zip file if you upload index.php without zipping it without dependencies it knows what to do but because I'm zipping it it can't tell we'll say please run it with PHP I would like dash dash web raw meaning please don't try and pass my incoming variables I would rather do that myself and know where my data came from maybe I'm being old fashioned about that maybe not and finally I need to specify where the code is that's the zip file that we just created so cool, we updated the action in fact we've created it but it says we've updated it now I've made it I need to set those parameters remember I need to connect to the database so I'm going to update the action give the name of the action and specify some parameters you just do that on the command line here and what I usually do is this step goes in the continuous integration so I just push to master and Travis says oh yeah, okay here's the script that I run here are the environment variables that are already set up I'll deploy these parameters with these actions or on OpenWis there are also packages so I'm setting a URL there this isn't the real URL so then there's like a little pause well I set it correctly in the other window so it's set to my real credentials and the whole thing works, brilliant now I'm going to get the URL of this action so I just say to the action what URL you want and it says this mess all of the serverless platforms offer API gateways where you can set up nicer roots and some authentication there you can also set it up so that there's like a disconnect between the URL and you can change which action it points to so that's really good for blue green deployment trying to keep it really simple today so that when I'm copying and pasting the raw web URL I often use webhooks just like this I'm not sure if I should say that I just grab the URL and work with it usually for the slack bot notification type stuff tend to just use this anyway, so yay let's add a new comment first of all I'm going to put that URL that I just copied in so that we register it as a webhook and then when I add a new comment the webhook will webhook here it is, yay more positive comments, there it is it's quite hard to show an incoming webhook but we did write to the database in our action that we created we wrote to cloud and so we can go and have a look at cloud and see our data there so there's our incoming data this is the incoming database holding incoming data I'm not confused at all and there's the data we can see it in detail here I'm learning so much learning so much and the metadata that we added as well with that new status so our action received the incoming webhook from the guest book and wrote it to the database and sent back the success response kind of give you an idea of how this would work do often also write to queues here at this stage put the incoming webhook data into a queue and then deal with it later that also works and you may want to store I'm using CouchDB this is cloud and it's the product name Apache CouchDB it's an open source document database if you've used MongoDB CouchDB is in the same umbrella area they're both document databases so you can store this nested JSON in your database if the fields are slightly different that's fine you can store nested JSON you can search nested JSON if you're not using a document database then you might want to extract some of the fields that you're going to want to search on but if you're using Postgres it has brilliant JSON support and the new and my SQLs have probably all the JSON support that you need for this kind of thing awesome one more thing I want to mention I have a slide on it is it this? No this? Yes one more thing I want to mention is Engrog in this example I was pushing my receiving code to the cloud making a serverless endpoint a lot of the time the development work that we do is on our local machines or on virtual machines and that's annoying for testing webhooks because you need a public URL to register so that the incoming webhook so the server can find your client but your client's on a virtual machine on your laptop inside the corporate network ok so the answer to that problem is called Engrog it's a brilliant tool you run it from command line saying which port you would like to tunnel from and it tunnels out to Engrog servers gives you a public URL and that URL if you use it allows incoming web stuff to come into your dev server this is brilliant for testing webhooks it is brilliant for testing websites on phones or other devices or asking other people in other locations to look at what's on your dev machine that's not the good part ok the good part is that Engrog has a dashboard it allows you to inspect in detail the headers and body and everything of request and response of all the traffic that's coming over here I use it a lot just to diagnose what's gone wrong between HTTP between two things that's also not the good part on that dashboard when you inspect the request and response there's a button and the button says replay so if your webhook is the webhook that github sends when someone adds a comment to a closed pull request on a particular open source project right you create that event once capture it in Engrog and if your response wasn't quite perfect change the code press the replay button press the replay button you don't need to do that it's when you're testing the webhook for when a new user has registered and it's convoluted but it's really frustrating so this is the good part of changing what you're doing so so powerful for lots of aspects of web development but especially these incoming webhooks key tool I had this in my demo and I took it out because I'm really using serverless now I had to leave the slide in to give you this tip okay by now perhaps you've realised that I am a huge fan of webhooks they've made my PHP applications dance and sing in a way that I'm not sure how I'd have implemented a lot of those features without this and I think in an increasingly componentised and event driven world all those big kind of rhetoric software architecture talks they tell you how that you should do things keep things separate they don't really tell you how webhooks are one way you can do that and it's a post request and suddenly all this stuff is within your grasp using them at the right time knowing when they're useful they're useful when one system or component needs to notify when an event happens another system where polling is less useful right so something happens we're going to broadcast it it's a pub sub it's event driven architectures I've tried hard to include what you need as a PHP developer and it's all vanilla PHP but you can do it in all of your frameworks and if you need examples come and see me of how that implements it I know there were a lot of moving parts here and I put in a queue as well you're a pretty qualified technical audience I think you can handle it and this is how I really do it I didn't want to bring you a dumbed down version yes there's a GitHub repo yes it's a simple example of any good shadow of how I would build a more complex system as an engineer I'm a developer advocate today that's not what I've always done crucially webhooks they're HTTP they're just the web you understand the web you already know how to do this you already know how to make a post request from PHP if you don't know how to make a post request from PHP you need to see me after class and this will enable so many things in your applications and with that I just have a few links to share and then I'm going to get you to the front of the lunch cube right so please leave feedback the organisation is using joined in it is a brilliant way to let speakers know what's working not working please tell me what's not working as well because I do this all the time so other audiences will have to sit through this terrible experience if you don't fix me if you want to try any of the stuff that I've mentioned check out IBM Cloud we have free tiers your PHP will run there on an ordinary hosting platform you can try out the serverless stuff as well we have my SQL on our platform let me know how that experience goes because my job to improve things and I would like to improve things for the PHP community specifically link to request bin, link to Engrock I rarely are not here this year which I would guess means you didn't buy enough books last year but I am the author of PHP Web Services which has a chapter on webhooks so you might find that useful as well here's the repo for the example app here is the PHP CouchDB library and with that I'll say thanks for your attention