Okay. So yeah, so hi everyone. My name is Nikhil Barthwell. I'll be talking about serverless application development using Azure Functions. So the way I have structured this talk is, half of the talk is actually going to be more about serverless, which is kind of general because Azure Functions is not the only implementation, is just one of them. The remaining half of it is going to be a little specific about the Azure Function implementation. Although most of the things that are true for Azure Functions is kind of true for other platforms also. So anyway, I'll start with what serverless computing actually is. So serverless computing or it's like to call a function as a service is another common name for it, is essentially a code that runs a set of functions that operate on certain input triggers and output triggers. So it's a code execution model where your logic is set of these discrete functions that run in a stateless manner, and they communicate with each other in a asynchronous way. They can run in a docker, they can run in a container, there are different reasons they can run. The whole underlying infrastructure is fully managed by your Cloud provider. So how does, let's go into details of what serverless application model is. So essentially what it is, it's your applications is set of independent functions and each functions what it tends to have is it sends to have a sort of input binding in the sense that it's also have certain trigger conditions, and then it has an output binding in the sense the action it can take. So for example, I have a function that every time you check into a repository does something, maybe pulls out the code, does some calculations, whatever it is. So its input binding is going to be that repository. Its output binding could be another, maybe call to another function, maybe generate a message when a message queue, could be anything, it's actually pretty flexible. We'll see an example of input and output binding. And when an event happens, it actually triggers that function. So certain event happens and the function is triggered, does some action, and then put some output. And the whole characteristic of this communication as that it's asynchronous mechanism. So what do I mean by asynchronous? Let's say that you have an input by function F1, and function F1 calls function F2, just makes a call. It doesn't really know what happened, what does F2 does? I mean, it might get an acknowledgement saying I received it, that's about it. But anything that F2 does after with that call or with that message that it delivers, F1 does not know anything about it. It has no traceability. And that obviously has its downsides and upsides. On the upside signs, you could have massive parallelization now because you can send multiple messages. On the downside, you have no traceability. So if something wrong happens, you don't know what happened. So there are some of the characteristics of serverless application. The first thing, and this is actually a common misconception is there's an abstraction of serverless. Now when you look at names serverless, it's kind of misleading because it sort of suggests that there are no servers. Obviously there are servers. You're running on servers. What serverless means is that they are abstracted out for you, so you don't have to manage them. That's what serverless computing is. It's an event driven. So asynchronous model, you have an event, take some action, generate some output, and you only pay for what you use. And this is actually one of the major advantages of serverless architecture is that it's cost efficient, as opposed to a traditional VM that it's running, it's running, it's running, you're paying for running, even if you're not actually using it. So for example, one of the common application that serverless has in IoT. So when IoT, you collect some data, you send that data, it takes some action. Now, if you don't implement the IoT as a serverless, if you implement it as a traditional model, you have that VM that's running 24 by seven, and obviously it's costing you money. And you might actually use it for like 20 seconds a day, but you're gonna pay for 24 hours. Whereas in serverless, you're using for 20 seconds, you actually would pay for 20 seconds. Obviously, the downside of it is that this function, it's provisioned, it's deprovisioned, whereas a VM is running all the time, which means your responses are gonna be very fast because it's running. Whereas in a function, if the function is idle and it has been switched off or put it in a dormant mode, every time you get a trigger, it has to actually wake up. So there's a certain lag in that it's called cold start problem. And I'm gonna discuss more about cold start and how you can avoid it, but that's kind of the downside. But essentially the key point is the whole serverless architecture is an event-driven pay-as-you-go model. Whereas in a traditional, let's say, microservice implemented in a Docker and so on, you're just paying 24 by seven. There's no concept of pay only for what you use. Lina, I think, sorry, that's, yeah, okay, good. Probably I'll just keep moving mouse, so it's easy. Yeah, okay, good. So let's talk about these functions. Now, the particular characteristics of these functions are they are stateless. The reason why you want them to be stateless is because they can be scaled up and scaled down. So if you have a state, the state cannot be scaled and scaled down. You do have like a persistent storage, like a database where these functions can read and write from, but the functions itself do not have a persistent state in them. That's the characteristics. Functions have to be stateless. And that's what makes them easily scalable. Like I said, each function would have a certain kind of input and output binding, right? Even gets triggered, function acts. And what happens often is that there are actually limits on the execution time of this function. This is actually more of a cloud dependent. I think Google puts nine minutes, Azure puts 10 minutes, AWS puts five minutes. There are variations in how you can provision these functions like they are different hosting plans. So some hosting plans would not put a limit, but they'll charge you more. Some hosting plans do put a limit, but they are cheap. So you have to basically determine what's the most, what's the right plan for your application. But the idea is, and the reason why they have a limit is the functions are supposed to be a small, small functions that work with each other. You should not have like what I call as a monolithic type of application in the sense big, bulky functions that do massive data processing. If you wanna do that serverless is not the right application. Serverless requires you to have small functions. You can have many functions that work together, but each function individually should be small and should act quickly. So what are the advantages of serverless application? To start with, every function is independent of each other. And when you have these functions that are independent of each other, they are independently scalable. What do I mean by independently scalable? Let's look at the flip side and let's say you have a monolithic. Your monolithic consists of different parts of the code. It's a big application.  Even the parts that you're not using heavily, they also get scaled up because it treats the whole application as one unit, one unit of scale. Whereas when you look at serverless, each function actually is an independent unit. So you could have like, if I have a function F1 calls F2, F2 calls F3, I can have like 10 instances of F1, but five instances of F2, three instances of F3. And how system determines is, if F1 is loaded, it will start scaling up. So what does it mean for you? What it means for you is more cost-effectiveness. Because you're only scaling up parts of your system that is overloaded and not scaling up parts of the system that are not overlaid it, actually you're consuming less resources as opposed to scaling up everything. That means less resources. So less money you have to pay with a vendor. You also have a better scaling, right? Because if the parts of the system are overloaded, you would scale up that part, but you don't really have to scale up everything. The second thing, the big advantage is there's a technology heterogeneity. What is a technology heterogeneity? I have these functions and they are communicating with each other. These communications happen through a lot of an agnostic, code agnostic way, open standards of internet, HTTP or whatever. So there is no limitation on me to have one function using one specific set of technology and another function using another set of technology. I could have one function in Java, call another function in Python, calls another function in C-Shift. I can do that. Whereas when you have a traditional monolithic application, it's an advantage even in the microservices world, but when you have a traditional application, you can't do that. You have to use the whole unit as one particular technology, one particular platform, platform and one certain set of frameworks, but you have the flexibility. Not only is it just about the flexibility of implementation, there's actually a lot more to that and in a way we all face this problem time and again. So what if technology stack gets rewritten? What if your technology gets outdated? If you have a big monolithic application or a big application and you want to move to a new language, a new technology, a new version, because it's a unit as a whole, you have to rewrite the whole application again. Whereas in a function, what you can do is you can do part by part. So it's a less migration risks and you see that all the time. So one good example was Facebook, right? When Facebook started, it started as a college, get platforms on. It wasn't designed to be the company it is today. And then it didn't PHP. The problem with PHP was it didn't scale, but that was not a concern when it was designed. So they created this monolithic PHP code base and suddenly they decided to start the company and the company scaled and scaled and scaled. The problem was PHP did not scale. What do you do? You could rewrite the whole system, lot of time, lot of money, lot of risks or you can basically make PHP faster. So they took the second approach saying, well, PHP as it is does not work. So we'll just make PHP faster. So they created this language hack, which is kind of a superset of PhD.  The whole idea was that your technology, whatever you're gonna work for, is going to get outdated sooner or later. And rewriting a whole application from scratch is a really big risk. So when you have these applications, Azure Functions or even microservices, which are implemented as set of modules that kind of assembly of services rather than having one big service, the migration from one set of technology to another set of technology becomes really easy. Because now you have a lot less risk. You also have less management overhead. Why? Because you don't have servers to manage. This is in a way an advantage, but in some ways it's a disadvantage because you're not managing those servers. You don't really can optimize or do anything with it. You have to just accept whatever your Cloud Winter is doing. So in some sense, there's a disadvantage also, but in most of the cases, I would consider it as an advantage because it frees you of a lot of burden and just focus on your application. And of course, as we discussed, it's cost effective. You only pay for what you use. And this is a major reason why serverless is getting a lot of popularity. So when you look at the evolution, the whole, and I know Gregor Hopp in the morning, he actually kind of talked about it in his keynote. It's like you make people productive by raising the level of abstraction. So you have the infrastructure, then you say, well, okay, fine, I'll have the platform. Then I say, okay, fine, I'll build you the whole software. Function as a service is just another layer on top of it. So it's like a natural evolution. You're going that direction of increasing the abstraction. So what are the disadvantages? Well, to start with, you have a distributed system and distributed system comes with its own problem. You have certain failures. You have the more moving parts of your system are gonna be the more your chances of something failing is gonna be. Also, the less visibility you would have. I mean, you have logging and all those things, but let's say in a monolithic world, A calls, B a function F calls function F2 and function F2 returns an exception, right? You get an exception, you can handle it.  But when you have a distributed asynchronous way, F1 calls F2 and you don't know what happened, right? It goes into this either. Okay, I don't know. So that actually reduces the visibility of system and then you need additional mechanisms like logging and other tools to actually monitor everything. But in general, distributed system always increases complexity. And in serverless, that's what you're doing. You're distributing your system into set of functions. Also, no functions have contracts, but I mean by contracts is they expect the data to be in a certain format, right? I send you a request, I send you let's say a JSON payload that JSON payload has to have a schema. Now, what happens in a monolithic world is that your schema is enforced by your language, right? So if function F1 expects a certain data structure and function F2 expects another data structure and let's say F1 calls F2 and there's a mismatch of data structure, you actually get an error during the compile time, right? Type mismatch on the statically typed languages. You don't have anything like that here because F1 and F2 are independent of each other. So if you have a contract mismatch, that is becomes a kind of a runtime error. You have no way of finding it during the compile time. There are ways how you can mitigate it. And again, I'm gonna talk about it, but essentially the interface management between these functions, it kind of gets difficult because of the distributed nature of the system. There's a latency, you know, F1 calls F2, you're passing through a network, network would have its own latency. It has a queue because being asynchronous in nature, the same function can receive multiple requests from multiple people and queues up, right? The order in which it processes. So this latency introduced in the system and then finally it's difficult to debug. Why? I don't have a call stack, right? I don't have the advantage of having a nice call stack. I don't have an advantage of enforcing those contracts or interfaces during the compile time. Everything now becomes runtime. It's a problem. So yeah, so it's basically when you look at the cloud as a whole, like the promise of cloud, what you're really doing is you're a lot of issues that you have size of the servers, monitors, all those things, you're kind of leaving it to the vendor. And what cloud really is doing is it converts your capital cost into an operational cost. Now, what do I mean by capital cost to operational cost? Let's say I wanna run an application, right? I buy it, I have to buy some data, not like land, build a data center or basically have some kind of warehouse where I put servers. There's a lot of upfront investment that I'm doing. When I go to a vendor like Amazon, I don't have to worry about all those things. So my upfront investment actually gets translated more into an operational cost that I'm incurring. A different, but a common example is it's buying a house versus renting a house, right? You buy a house, you put a lot of investment. It is cheaper in the long run in the 20, 30 years period because you own the house.  It gives you that flexibility to increase or decrease your stay. So in a way, cloud is kind of doing the same thing.  And there are so many of the issues like size of the servers, monitoring security.  It's actually very weird that some people are afraid of moving to the cloud because they don't want to trust the vendor and, you know, they are afraid of their data being stolen. The truth is, typical vendors like Amazon, Microsoft, they spent like billions of dollars on security. So the chances are their security is gonna be better than you because it's what they do. It's what they specialize. You know, you're, let's say an insurance company or some kind of other traditional oil and gas company doing some data processing. It's not your domain. So I don't know why people have this notion of having reluctance to move to the cloud. So when you look at the computing era, right? We started with mainframes and we had these dumb terminals connected and slowly and slowly we moved to a client server architecture. And when you look at the client server architecture, what you're doing is you're distributing the processing between client and server. And you had two tier architecture, three tier architecture and so on. And then you moved into agile. And finally, the cloud. And when you look at this transformation, there are these two factors that are actually happening. And one of this is you're increasing the velocity of your development, right? You're moving faster and faster. That's what agile is all about. It's what this conference is all about. At the same time, you're decreasing the cost and the size of the risk. Why? Well, to start with, when you're going to a cloud, you have multi-tenancy, right? So that decreases the cloud because they have the economics of scale, right? The infrastructure is actually shared across multiple people. So the cost per vendor per client actually goes down. So these are the two driving factors. And when you look at a function as a service or serverless computing, in a way it only drives these two levers, right? It takes them a bit further. So I can have better velocity of development because I don't have this overhead of managing servers, so on. And I have less risk, right? I have these independent functions that I can just change, modify anytime. I can involve, I can transform. I don't have to worry about this big service doing everything one at a time. So serverless, there are certain misconceptions. The first thing is there are no servers. Well, I mean, there are. You just don't have to manage them. And because you're not managing them, you don't have any control over them. And that, again, becomes more of a, it's a double-edged sword because you can't optimize and so on. I mentioned this before. Most of the time, this is an advantage because you don't want to deal with all these headaches of management and also hardware generally is cheap, right? So you shouldn't really worry about optimization and also you could scale up and down because primarily, at least in serverless applications, you have these stateless functions. Scaling up and down becomes easy. So it's usually in a typical organization, your expenses are on the developer's salary, not on the infrastructure, right? So in a way, you're trading money saved on developer's salary, even though it might, might, and I'm using the whiter, increase a little bit on your infrastructure side, that's okay, that's a good trade-off to me. So there's a natural evolution, right? When you look at cloud resource management, you have like, you think about, like an on-premise solution, you basically manage everything, right? And then you move to infrastructure as a service. What you've really done is I don't care about hardware. Where is managed by somebody else? And then they are virtualized. And then I have these VMs. I provision those VMs. I have these operating system images. I choose what operating system it is. I apply the security patches and all those things. That whole operating system that VM is mine, right?  I don't want to manage operating system, why? I mean, I have the same version of Linux on my local machine. I can just run the same version of Linux. Why should I worry about patching and all those things? So it's raising the abstraction a little more that you don't worry about operating system and runtime. And that's what platform as a service kind of gives you. So moving forward, function as a service takes one more step and says the application, you know, the application of how your different functions and all those things are gonna be abstracted by me. Just worry about these individual functions and triggers. That's all. So it's, in a way, it's a next evolution beyond infrastructure and platform as a service. So there are a lot of commercial openings. I'm just gonna talk about three of them because these are the dominant one. So Azure Functions, which is most of what my talk is based on. Then we have AWS Lambda. AWS was kind of the pioneer in serverless. They, I think it was released 2015. And relatively new entrant is Google Cloud Functions. I had a little bit of experience with Google Cloud Function. Unfortunately, it's somewhat limited. It just, you can't use anything but Node. Node.js actually to use. And that was a severe limitation for me because in the organization I was working, they were like Python and Java guys. They couldn't do much. They were more comfortable with AWS. Azure also supports predominantly.net. But they are expanding their support to other languages. But there are other, I think Rackspace has, I'm not sure, but there are other implementations of serverless. These are the three dominant ones. Okay, this is a little bit of digression, but I'll tell you. There was actually a full talk about it. In a way, yes. There are certain limitations in the sense that in the design philosophy, functions tend to be short burst like with a time limit of five minutes. Whereas microservices in the design thinking does not have any such limitations. You just, it's a service. They actually, you could implement microservices as form of functions also. And there's a full one hour talk on serverless versus microservice which actually kind of goes into the details of pros and cons. But you're right, they're along the same way. The common philosophy is that your service your application is an assembly of services as opposed to a monolithic. So that's the common binding theme between microservices and serverless. Where they kind of differ is how the services talk to each other and certain assumptions around that. Typically, and this is, it's not always the case but typically what microservices, especially the event-driven microservices what they would have is they have a broker, the central broker Kafka or Rabbit MQ and services to read and write. It still uses an asynchronous method of communication. But it has a central broker. Functions on the other hand, don't have any such concept. They don't have any such concept or central broker. A function F1 would call F2. The microservices design philosophy is that each microservices are decoupled with each other in the sense that I'm programming a microservice I don't have to worry about it. So in a way, if I'm using a microservice I just have to worry about interacting with the broker. I don't have to worry about other microservices. They can read and write. I'm just injecting in into the broker. Serverless does not achieve that kind of decoupling. Why? Because in serverless you don't have the broker. So F1 has to call F2, F3, F4. If you change your contract or you change the way your application works F1 has to update itself. Let's say that in a typical application F1 was calling F2 and you made a decision I'm gonna change and I'm gonna say F1 should call F2 and F3. In an event-driven microservices where you have a broker F1 injects a message to the broker. F2 is already reading it. You just have F3 subscribe to the topic and read it. F1 doesn't need to change for that. You're just adding a consumer. The producer stays the same. In serverless you don't do that because you don't have the broker. F1 now has to change that it has to have an additional output binding that actually calls both F2 and F3. I would rephrase it and say that functions have similarity to microservices. I would not say that they are the same. I think there are implementation differences and they are design philosophies differences. Of course they are kind of substitutable in the sense that you can use functions for microservices and so on. So there's a, again, the commonality is that it's an assembly of service. So your individual component. In fact, I would say that most of the modern applications that you would see is not going to be serverless and not going to be microservices but it actually will be combination of the two. And... Oh, yeah, they can. So let's say that you have an application model. This is more going towards the microservices world where you have a broker. You could have a function that writes to that broker and you could have a separate assembly of functions that write and read from the broker. So for that to happen, the function can have an input trigger to that broker to read that message. So both can coexist. Why would both coexist? Well, the reason why both will coexist is in an application you have tier one services that impact your customer. Typically tier one will follow request response. So they are like typical synchronous communication pattern. Then you have tier two services which kind of semi-impacts customer. But then you have these tier three services that are not really typically important. You kind of need them but you want them to be cost-effective because they are not impenetrable. Serverless is going to be more cost-effective than microservice. So you would have an application where you have these different components, microservices and serverless function and broker and possibly other traditional request response systems all operating simultaneously with certain components implemented in a certain way that best describes the need. A similar concept more going into cloud computing is hybrid computing. That's what hybrid computing does. You have your own data center, you have the public and they can talk to each other seamlessly. What's the advantage? Well, it's more expensive to have your own data center but then you have better control over it because it's yours. So typically how banks would do, banks can't put a lot of data because they have a lot of regulatory concerns. You're putting your data in somebody else. So banks would give the most important information that they have, they will have it in their private data center. The ones like customer service they'll have in the public. And typically let's say in Microsoft context you can buy this Azure software stack. So you can buy all these Windows Server system center all these products and run your data center and this data center is gonna be identical to the Microsoft Azure data center. And then you can have an application that is in part your private and in part public which can talk seamlessly and because you have the same software stack tomorrow you decide I want to keep this data not in my private data and I wanna move it to the cloud or vice versa. You can do that seamlessly. So that kind of thing also you could do it with Microsoft services and Azure functions. In fact, I'm gonna talk about Azure runtime. You also have a hybrid cloud concept in serverless computing because you can run the runtime of Azure functions locally and have them interact with Azure functions running in the data center again in the same way for the same reason that you have hybrid computing. Or for another reason, let's say I'm doing a development, I wanna test it. It's very hard to test it on the public cloud. I can do local testing. So I can build this environment that is a replica of my private, in my local machine test everything and when I feel confident, move it. So yeah. So there is a concept of hosting plan. There are different hosting plans. I have a slide on that also later on. So I'll explain in details but they have a different hosting plan. You have to choose. And in short, you could have like a kind of a container based system but then you're paying more because it's running 24 by seven, right? Then you don't have the startup and shutdown. You also have the other option that I want to make it in the consumption plan. In the consumption plan, it's like it pops up when you need it and then shuts down when it's idle but then you have the cold start problem because if your function is idle and you get a request, it has to start. I actually gave another talk on unique kernels and one of the things I actually talked about in unique kernels was because they can they can be shut down and be provisioned very fast. They boot up in millisecond. That's an alternate implementation that you have. Tiny unique kernels, you can implement microservices or functions or whatever you like to call it in these unique kernels and do a just in time provisioning. When you get a request provision them, the advantage of unique kernel is the boot up time is extremely fast because they are very small images. So you can do just in time provisioning with serverless, you have a limitation. You can't really do just in time provisioning because they're still containers, right? They need time to boot up a few seconds, few minutes. Okay, okay. So I'll answer your question. Sorry, I don't have a watch. So I'm actually, you know, okay, that's okay. I can go faster. So Windows Azure provides you a lot of functionality. I kind of talked about it. It's a serverless offering from Microsoft. There's an open source version Azure Web Jobs SDK and you can have the ability to run on cloud and on Chrome. So that's what I was talking about. Azure Function Runtime. Azure Function Runtime talks about hybrid cloud. So I can have part of it in my private cloud and part of it in my public cloud and they can work seamlessly and that way you don't have the possibility of, you know, vendor lock-ins, right? Because now you're running it locally. You control the environment. So these are typical characteristics of Azure Functions, right? I already discussed most of them. This is more in context of Microsoft. The key thing is that there is a trigger for input and trigger for output and it's an asynchronous execution flow pretty much. Like this is gonna be true pretty much for any serverless offering and AWS Lambda might have a different constraint but they'll operate on the same way. So these are the supported bindings, right? There's a full list. This is just a partial list. There are inputs and output. You have in Azure, you have blob storage which is basically your blob. You have queues for short 8KB message sizes. You have tables to store key value pairs and you can have all these input and output binding in the sense that if I send a message to the queue, that will trigger an event that will call a function. Same thing. If I can send a message back to a queue, I can inject this message back into a queue, right? You can have both input and output. You obviously would have rest, input and output. You can have scheduled like, I want the function to be triggered every 10 minutes. DB streams and so on. So a lot of different notification. This is the official Microsoft site. So kind of gives you all of the input and output bindings. HTTP one does not have, it's actually a rest of web book. Yeah, yeah. So this, like when I prepared this slide, this was updated, but actually you would want to refer to this because the information keeps changing, right? So this is actually the reference link for it. Okay. One of the problems with infinite loops is, infinite problems is that you can get into infinite loop because it's an asynchronous message, right? You can get into a cycle. F1 calls, F2, F3 calls, F4 and F4 back calls, F1 and then you get into a circle. So you want to avoid this because then otherwise you have very little visibility in the system and then you just end up with a big bill. So how you avoid it is you pass the call stack, right? So you pass the call stack. So if you get into the loop, you have some mechanism to stop and stop processing or at least stop this infinite loop. This is actually true for any system that supports a cyclic graph, right? Typically let's say build system as a directed acyclic graph of this very reason that it wants to prevent the cycles. In functions, as serverless, you don't really have any such thing as I want to prevent a cyclic graph. So you can get into an infinite loop. Functions are stateless, but you have these persistent ways of storing, right? File, queues, table, blob. Blob is like the big chunk of data. Tables is key value pair, queues are short. ADC has messages and then you have the file. Functions by itself should be stateless. Startup latency, you want to keep that. So typically when the function boots up, you want to keep the external dependency to minimum because it'll add a startup time, right? After a period function gets idle, this is what I call as a cold start. Idle functions have to boot up. So they'll take time. There is no cold start problem with app service plan. We'll talk about what apps are. So these are the hosting plans. So this kind of answers your question. In app service, you have these VMs running in a container where they kind of run 24 by 7. That way you don't have any cold start problem. You don't have any limits on execution, but obviously it's going to be more expensive, right? Consumption plan does the opposite. So based on your application, you would have app service plan and consumption plan. You can have both operating simultaneously. Some of my functions are on consumption. Some of my functions are in app service. Typically the user-facing functions are going to be on the app service plan because you can't afford the latency. So user-sensor request, you get an acknowledgement immediately. The ones that do backend processing can go on consumption plan. So in the Azure portal, you can create these functions. If you want to learn that's how you do it. In reality, you actually won't do it. I'll talk about that towards the end. I don't have a slide on it, but I'll still, I think just verbally talk. Testing a function can be hard because you don't really have the visibility. It's an asynchronous. So you can test functions using command line curls, test functions within functions, write the wrapper functions to test a function, test in browser. You have different mechanism of testing these functions. You can run them locally. But yeah, testing functions can be tricky. Monitoring. So Azure portal will provide your monitoring tool. So you can monitor. You have logs, I think there's, yeah. So there are execution logs also. Okay, so before now I have a little bit of time. So I'll actually go into some stuff which is not in the slide, but I think it's kind of important. And what it is is how do you build a large scale application, right? Now in a large scale application, what you have is you have these various sub, each function as a project by itself, and then they share the contract. So usually it's a good idea to keep the contract file separately. How do you keep the contract file? There's a, in C sharp and F sharp, they have entity framework. They have type providers that basically converts format of data into chunk of binary. Otherwise you have protocol buffer, Google protocol buffers that can generate code for various protocol formats, right? So how you do it is you have these contracts and then you have these functions that import and in your build system, you would generate the bindings, sorry, the stubs for these contracts and your functions would actually import that. So that way you don't have a problem of an impedance mismatch. That's how you would actually do a large scale. And in a large scale, obviously, you don't go to the portal, right? You would deploy it via command line. So Azure, there's an Azure CLI tool, Azure command line interface. So pretty much what you can do on portal, you can actually do to command line. So how you would actually do is you would have this repository. You would check out, you would build, you would make sure that all the contracts, if function one and function two are calling each other, they share that common contract, both function one and function two, import that contract. Why? Because if you change that contract and you forgot to change F2, during your build time, you will get an error, right? So you have these contracts and let's say each one of these functions are now generated as binaries. And then you wanna deploy these binaries to your actual production environment using CLI. The tricky part of it is, let's say you have one repo with all these functions. If you change a contract, if you change one function and it's easy to deploy a function, no problem, the tricky part is when you change a contract. Because when you change a contract, you might end up changing several functions that depend on that contract. So what do you do? When you build it, you have different binaries. How you could potentially solve this problem is that when you have these functions on your environment, you actually kind of, the binary, you can have some kind of hash code for it. So you know which version is running. And when you build it, you have different, you know, DLLs or EXC or binaries generated and you can compare the hash code because the problem is you don't have a, you have an atomicity of commit, but you don't have an atomicity of deployment, right? You don't want to deploy the whole thing when you actually just change four functions. So you wanna keep track of what is running in your system and what has changed. And then you can use these hash codes to just deploy the parts that you actually need and leave the part that is running. How much time do I have? Almost up. So that's about it. I can take more questions if any or we can have an offline discussion. See, this is more of an experimental than a theoretical thing in the sense that you can't put a limit saying cold start will take two, three times because it depends on several factors, right? The cloud has provisioned a server depending on the speed and overall because you're sharing that server with other people, right? It's hard for you to put a number saying it takes two, three times. I mean, you could do it in a couple of few seconds, few minutes, something. Yeah. You would, I know it's pretty cheap. I know the numbers for AWS. You were talking about few cents per car or something. So it's pretty damn cheap. And when AWS Lambda came, some person, they were playing and they actually got into an infinite loop. And even then the bill wasn't that high.  So I would not worry too much about them unless, you know, I don't know, you're processing like millions, maybe yes, but generally they're pretty cheap. App hosting plan, that could be expensive because you're running 24 by seven, right? Okay, so any other questions I'm around, you can ask.


of the site over the board, the site over the board of the weapon. All right. We zeroed our weapon at 300 meters and in that space, in that simulated space, the round will rise enough to hit where that site is aiming at. All right. Safe to semi. Boom, boom, boom, boom, boom. All right. Look left. Look right. Check your safety. Same drill, same drill. Stand by. Contact front.


Suppose the members of a population either have a feature, type A, or don't, everyone else, taking a sample of size N and determining how many are type A is a hypergeometric experiment, but if the population is large enough, it's approximately binomial, and if the sample is large enough, it can be approximated by a normal distribution. For example, suppose that 15 million people support Proposition A, while 14 million do not, let's model the number of voters in a sample of N equals 100, who support Proposition A. Now, the empirical probability the first voter chose and supports Proposition A is... Now, this probability will change a little bit because if we draw a supporter of A, then the number of supporters of A drops to 14,999,999,999, and the number of actual voters also drops, but it doesn't change much over our N equals 100 voters, so it's approximately binomial, and we can approximate this using a normal distribution. So we compute our mean and standard deviation, and this is a borderline case. Our standard deviation is just a little bit under 5, but we'll go with it. And so we have a normal distribution with mean 51.72 and standard deviation 4.997, and so 95% of the time the number of supporters of A will be within 1.96 standard deviations of the mean, or between... That's the probability side. What about the statistic side? Suppose our sample of 100 voters included N supporters of A. Could we use the same interval to give a 95% confidence interval for the fraction of voters who supported A? And the answer is... No. And here's the problem we've run into. Suppose you pull 100 persons and find 61 of them support Proposition A. Let's try to find a 95% confidence interval for the number of respondents that you would expect to support Proposition A. So if we assume our proportion is 61 100s, then the number of respondents who support Proposition A should be approximately normal with standard deviation. And our 95% confidence interval will be everything within 1.96 standard deviations. Now we could claim the percentage of supporters of A is between 51.44 and 70.56%, but we'd be wrong. Maybe. So here's where the problem arises. Our data seems to support that up to 70% of the population supports Proposition A. But if 70% of the population supported A, the number of respondents who support A could be approximated using a normal distribution with mean and standard deviation. And in that case, 95% of the time we'd see between and we wouldn't see our observed value. In other words, if the claim we were making was true, we wouldn't see the data we're getting. Now we should take into account the shifting of the confidence interval. But in practice, we ignore it and use the observed empirical probability as the probability of success. And since we're going to use the empirical probability as our probability, we can just report that value. And this is the population proportion. But we often just call it the percentage of respondents. So here's how that works. Suppose 61 of 100 respondents said they supported Proposition A, find a 95% confidence interval for the population proportion of supporters of A. So we already determined we'd expect to see between 51.44 and 70.56 persons who supported A. And since we pulled 100 persons, we'd expect to see between .5144 and .0756 of the population supporting A. So let's put this all together. Suppose we pull n persons and find x of them support Proposition A. The confidence interval for the number will be plus or minus some multiple c of the standard deviation, where we use for our empirical probability the number who supported A divided by the sample size. The confidence interval for the proportion can be found by dividing by the sample size, which gives us. And if we wanted to, we can turn this into a result for the standard deviation for a proportion. But remember, don't memorize formulas, understand concepts. So you're better off ignoring the formula. For example, suppose a poll of 8500 voters is taken to determine whether they would vote for an abusive misogynist endorsed by a con artist. 4087 said they would. Let's find a 95% confidence interval for the fraction of voters who would vote for an abuser endorsed by a con artist. We can model this using a binomial distribution where our probability of success is our empirical probability 4087 out of 8500. And the number of trials is 8500. And we can model that using a normal distribution with mean and standard deviation. And so the number of supporters out of 8500 can be modeled using a normal distribution with mean 4087 and standard deviation 46. Now our 95% confidence interval will be all values within plus or minus 1.96 standard deviations or between. And since we pulled 8500 persons, the confidence interval for the proportion would be and as proportion we would probably express this as a percentage say between 47.02% and 49.15%. Alternatively, since our confidence interval is everything within plus or minus 1.96 standard deviations of the mean, the number of supporters is going to be in the interval. So our proportion is going to be between. And again, we can convert this into a percentage. We could say this is 48.1% plus or minus 1.1% where we've rounded our values to the nearest tenth of a percent. Or we can use a formula. The sample proportion is 4087 8500 or 48.08. And our proportion standard deviation will compute the formula and the 95% confidence interval will be plus or minus 1.96 standard deviations. And this gives us our 47% to 49.1%. And again, since 1.96 standard deviations is about 0.11, we might report our result as 48.1% with a 1.1% margin of error.


President, fellow, and guests, thank you very much for the invitation to come and talk to you tonight. I'm pleased to say that I'm done with Kangaro, but you will also be getting mail for part for the second half, so we are doing hopefully not a comedy double act. And we're going to be talking to you tonight about the project we're working on at the moment. It's important to say at the outset that Mel and I are here tonight. This is very much a team of great good researchers. It's nice to have heard Neil Wilkins' name mentioned just a little while ago as being elected in the FSA today. I think that was what you were announcing. Along with Anne Wayne and Trina, who may all agree, I'm sure have been doing a lot of the work so far. This is an AHRC funded project. It's 42 months long altogether. It started in September 2016, so we're two and a bit years into a three and a half year project. So while in some ways it doesn't seem early days also, hopefully we can latch on to the idea that it's early days as well. And we're looking at grave goods from the near of the end of the I&H on the project. From right from the very start, we focus on the hung that is encapsulated in the term grave goods. In that these are objects found in graves, but they're also objects that we feel need to be taken seriously at a variety of different levels and need to be taken into account in terms of the full range of grave goods that existed in the past. So, well, maybe someone would argue that the gold cup in the middle there had received them in the Iron Age mirror, and those fancy things had received a lot of attention. Perhaps the pots down the bottom left, and even to an extent the copper dags down the bottom right, have arguably received less attention. And our point from the start of the project has been that the full spectrum of grave goods needs to be taken into account when we're talking about objects in depth in late prehistoric Britain. The core questions of the project are listed up there, as you can see. The first is a dual question really. What do we mean by grave goods? And also what do grave goods mean to people in the past? We've been wrestling with that first one a bit over the past few months. It's remarkably difficult to do, especially when you should know what you're talking about when you're running a grave goods project. And the second question is that we're asking whether we can move, and hopefully answer to this is yes, from an impressionistic or an assumed understanding of change through time of prehistoric Britain, a real and informed one, and hopefully I'll bring out in a bit more detail in a minute what I mean by that. So, what I do mean by that question is up on the picture in visual form is that impressionistic understanding of burial, how grave goods come into that sequence. So, we know that in the Neolithic grave goods in Britain, grave goods are relatively uncommon. The primary focus of mortuary practice arguably was the deposition of human bodies and then the intermingling and removal of some, that kind of idea. Then the story goes that we're not quite sure what happens of the only Neolithic in many places, but in the early Bronze Age, as you can see with that beaker burial, we see a flourishing of grave goods and the visibility of the burial practice and grave goods being caught up amongst them, as exemplified by that beaker and right in the centre of that photo. Then, towards the latter part stages of the Bronze Age, grave goods become slightly less impressive arguably, or at least that's been the narrative that's been told until we get into the Iron Age, which is a confusing narrative of burial and grave goods to tell, because different regions come in and out of focus and different things happen through time and they're not entirely coherent, but nonetheless extremely interesting manner. So, that's the overall story that many, if not all of the people in the room, have in their minds already. In order to try and encapsulate that, at the beginning of the project we sat down as a team and drew a squiggly graph to represent that. So hopefully you can see the caption down at the bottom in terms of, we're talking in the different lines of number of burials, number of grave goods and the variety of object types. So you can see clearly lots of burial in the only Neolithic, a big peak in the early Bronze Age and then another great big peak as we move into the late Iron Age. So I need to emphasise at this point that that is us sketching an impression at the beginning of the project. So hopefully that's the kind of impression that people are interested in with late prehistoric grave goods in this room would also have approximately drawn. And we'll come back to that graph in a little bit. So that's the impressionistic understanding of change that we had at the start of the project. And in order to move away from that impressionistic understanding of change what we wanted to do was essentially make sure that we could build that understanding and create that graph on an actual empirical knowledge of what goes in grave goods. And we wanted to do that throughout but from the very start of Mel and I discussing the project we wanted to do it as a long term thing to try and encapsulate the evidence and flows of practice through over that course of 4,000 odd years. But we knew that we couldn't, you know, ideally we'd have liked to build a database of every single grave grid cross Britain throughout that period but we knew that was logistically impossible. So in the end what we decided on was to focus on six case study regions that you can see. And this is a very, it was a difficult process to go through because you had to decide what was going to stand for the whole country. But overriding our desire to know everything was our desire to encapsulate all of the material culture because that concept made the call of the project from the start. So you can see that we selected the out-of-head for these in Orkney, East Yorkshire, Gwyneth and Anglesey, Cornwall and Silly, Dorset and Kent as our case study regions. We also had, I couldn't go on for a while about the process through which we chose them. The key to that choosing process was the need to really have quite good burial records throughout that period because it would be perhaps a more representative story if you chose a less vibrant region in terms of grave goods. But it would perhaps be arguably be a less interesting story as well. So through that, those case study regions they would come in to stand for national trends. In doing that we could look at regional patterns of similarity and difference at least in the regions that we're looking at in depth. And another part of the process which has been very important to the project is the process of creating that data which has been a more lengthy one and has brought out lots of information and ideas that only come about through engaging in that data in detail. And as we finished the data we finished the data construction process now and we've moved forwards into the and we're already moving forwards into the more rich, textured narratives it's been that process of data gathering that's enabled us to know the next step and the next things that we're interested in essentially. So, as I've said already, hinted at already, our aim has been to focus on the entire material assembly that's caught up in Beryl Maw, just the fancy stuff as you might call it. We want to draw out long-term trends and shift the focus away from the peaks of the grass from the early Bronze Age or the late Iron Age to those other phases within our study period perhaps less prominent in narratives and give them equal prominence so that we can compare the peaks in the different periods. So, some of the themes, the theoretical, interpretive themes that are in the background of the idea to do this project were thinking about objects and human biographies, material agency and meanings, so the power of objects and the way in which we can try and get to that meaning, how objects come to be caught up in death and the emotion surrounding that. The motion, the long link between wealth and status and objects has come under and off the screen in the end of the past 20 years, I guess you could say. That was one of the things that we were keen to take forward and investigate further and the critique of that. As I've said, to look at the small things as well as the fancy ones. So, in terms of what the project is going to produce, it's going to produce a database of all of the grave goods in those areas. Two papers that we're making good progress on at the moment. One's going to be about containment and wrapping in burial in a variety of different perspectives and the other's going to be investigating the deposition of grave goods as part of the much wider spectrum of depositional practice including hord and other ritual deposits. We've come to realise whilst conducting a project about grave goods that once you start to look in detail at those grave it's quite hard to stop to actually define what was a grave and then it's quite hard to sometimes to see where a grave in the deposition of human bones stops and a horde or a structure of deposit ends. So, we're looking at that in the second paper. We're going to produce a book about the project summarising all the other results and lots of nice things. We've already had our academic conference in Manchester earlier this year and we've got a more public focus conference coming up in the British Museum next May. In terms of the project's wider impact as we call it we're doing various things including creating teaching packs about prehistoric archaeology in general but focus through burial which are going to contain poems written by the ex-children's laureates and internationally famous really poet Michael Rhodes and disease appearing in that photo. A character needs to produce some great poems for us which has been fantastic as well as a series of reconstruction images taking different forms created by three different artists. We've got a visualisation of the database. You can see down at the bottom there so that people can engage with the sites that we've put into our database in a public facing website as well as a much more substantial database which will end up with the archaeology data service and we'll be reintegrating the data that we've now enhanced through the process of creating the database automatically we hope back into historic environment records so that as archaeology as a whole and the statutory records that are exist of it will have been enhanced by our research in a genuine and meaningful way so rather than having a separate database a lot of that data will be incorporated back into the HGRs at that fundamental primary point of contact that researchers and practitioners have with the record I take a while to ponder those pictures up the top is the Egyptian gallery down the bottom of the prehistoric galleries and Neil chose those images of the British Museum you'll notice the rather and I know they're slightly rostaged but chosen carefully but in a very real sense the Egyptian gallery and the grave goods within them see intense focus of interest and activity the later prehistoric ones perhaps less though so we're going to be enhancing some of the key displays in that gallery with some of the knowledge created through the project and just a general sprucing off of key grave goods within the gallery and we're also going to be constructing the grave goods trail around the British Museum building on the kind of concept that everyone will know from the history of the world 100 objects it won't quite be a history of the world and 100 grave goods but you get the idea that people will be able to follow a trail a themed trail around the museum that's focused on grave goods as you can imagine substantial numbers of the objects on display in the British Museum are of course grave goods so that's the project in outline I'm going to give you a broad scale of some of the results so far and then Mel will take you into a more textured investigation into grave goods in the second part so that's the numbers so over 1000 sites nearly 3000 graves over 3000 variables nearly 6000 objects are included in the database and you can see dense red dots of sites in the key case study region so a lot of data to work with and a lot of objects to think about I'm sure you'll agree so of course as I said it's important to bear in mind some caveats we're doing it in 6kw not everything so you can't produce nice national scale plots of what finds a way but that cost has come with benefits of much more detail knowledge and analysis in other areas we haven't been able to include all the variables in our database we've only included the ones with grave goods because that would have involved a whole different level of engagement and recording of the data it's too much although ideally we would have liked to have done that we've included all the formal variables but that's complicated to find and hopefully Mel and I will be able to pass the definition of formal variables on to Aminatrina maybe when it comes to writing the book because it's a complicated one because there are very blurred edges to deal with but you have to deal with it in a rational way that we will be able to explain but it's been tricky as has the Neolithic he can say having worked on a lot in the Neolithic over the course of the past few years but it has been difficult to handle because think back to the beaker barrier you've got a nice grave and you've got a beaker and some daggers but within a confined grave and a coherent body but in the Neolithic you're getting a much looser relationship between the material and the body and the individuals you're getting tunes into which people come in and out so not only do you have fewer grave goods you also have a much looser relationship between the people buried in there and the objects that ended up in that tomb and that's a difficult one to deal with because we don't want to it is very interesting which objects end up in Neolithic tunes but it's very difficult to tie those objects often to people and ultimately this project is really about that so the Neolithic doesn't quite work in the same way as other periods but we can't just ignore the Neolithic but it has been a tricky one to deal with so back to that graph in terms of broad scale results that's the one I showed you a minute ago and that is the one that we've now been able to create on the basis of all of that data that I showed you a minute ago and again it's a side fabrication because on the Y axis I've had to sort of score actual empirical data giving marks out of 100 because obviously burials of great numbers of grave goods and variety of object types aren't straightforwardly comparable but you can see if I put up the kind of annotations I hope you can read the text it doesn't really matter if you can't the number of burials in the early Neolithic is not as high as we expected hopefully you can see up the top there that blue line in terms of the number of burials has extended much further into the middle and towards the later Bronze Age than we expected so you're keeping the high number of burials into the middle Bronze Age and you can see with the variety of object types and the number of grave goods that drops prior to that so you've got a different unexpected relationship in terms of numbers of burials versus the number of grave goods as you go down the bottom there the extent of the loneliness I'm sorry I seem like an ugly word but I couldn't think of a better word of the later Bronze and Early Age in those two categories of numbers of burials and numbers of grave goods and then the extent of the the height of of the late Iron Age basically was perhaps surprising and it was higher than perhaps we expected so that's the the wiggly graph on the basis of empirical information so no significant changes because of course we knew what we knew what we had a rough idea of was based on evidence but it can become nuanced and it can come empirically based rather than imagined hopefully you can see these graphs so just a few interesting patterns to bring out so you probably can't completely see because the font's very small down the bottom but we've divided our data into time sizes of 100 years so early mirror things on the left and first entry ADs on the right and then you can see as you'd imagine objects starting to take off and this is raw numbers of objects compared to raw numbers of graves and you can see that peak in the early and middle Bronze Age and then that dramatic drop and then the rise so we were able to chart these kind of patterns through time really nice and you can see that they're broadly echoing one another but there is the difference between the objects and the graves extends as you get more of it going on so the distance between those lines gets accentuated at times of peaks on the graph this is another pattern that we wouldn't have expected but we can actually report it and represent it empirically so that we have a peak of incubation slightly earlier in the early Bronze Age and then cremation takes over but through the time slice approach and the large scale of data collection that we've done you can actually graph that empirically and you can see incubation dropping off and cremation really taking off into the late Bronze Age and then that pattern is swapping over again in the late Iron Age so at the moment it will be great when we come to write about these things in the long term but at the moment it's just hopefully impressive that we're able to represent those kind of patterns empirically another interesting graph we all kind of again expected the early Bronze Age it's quite well established that male graves especially in the early parts of that are often the ones that are that contain grave goods and that are originally represented in terms of material culture perhaps surprising that the female part of the graph according to traditional narratives is so close to the male in that part and then you can see broadly following each other until really interestingly in the late Iron Age the number of female burials actually is much greater than the male in the late Iron Age which is not a pattern that anyone as far as I know has been able to demonstrate or have thought about previously is very interesting in itself as well of course these are patterns that are in the case of where there are sexual barriers there you can see the number of materials so that's like things like copper and pot and tin and you know what I mean and the types of objects and you can see again an accentuation of the time when you get more materials you get even more object types or perhaps I should say it the way where you get loads of different object types they tend to be made in lots of different materials so again you can see a close mirroring of an accentuation of the piece a bit like we saw with the burials and the other kind of thing we can do is graph how what proportion of graver bits pots make up of all graver bits and when we created that graph in a way the surprising thing was how constant and even it was through time so you can see the little holes and quite a large drop in the towards the middle and the late iron age but otherwise in a way relatively constant proportion through that period of all graver bits pots are representing and that's a slightly tricky graph to explain but this is the mean numbers of graver bits and the dots represent the outline of the statistical spread of numbers of graver bits so through that kind of graphic representation you can start to see that you get some grades in the early bronze age and the middle and late iron age with loads and loads of disproportionately numbers of graver bits so you can begin to think about hierarchy at least in terms of numbers of graver bits rather than necessarily social hierarchy through the statistical analysis of the data that we've collected so I think just to come to a close with the broad scale of having it's very important in empirical basis on which to build it's tricky with the dots on the maps because they are in regions so you can't bring out that nation work pattern so you have to stop thinking in that way and I'm thinking that in a way are naturally the nations archaeologist is to think in terms of distribution maps but our distribution map is a false one because they're all separated regions you can't join up the two but as I said earlier the macro scale packing that we've been able to interrogate plays those places on a firm basis on which to move on and to build interpretations about graver bits so on that note I'm going to hand over to Mel give her some water then I'll be watching Thank you, now I've done this on the hard work with the database of the sysys it's my job to try and offer a few thoughts about where the project is taking us conceptually and to do that we want to go back to some of our earliest definitions the very term graver bits we're trying to track when that emerges in the literature and our first accounts where that's used as an actual concept seem to date to the 1880s and it's this definition at the moment where we are always ready and willing to accept new ones where that seems to be used in this very specific manner to describe a range of objects that are listed that are found with the dead however I had a great privilege a few weeks ago of being shown a first edition of Sir Thomas Brown's Hydro Teffio which is one of the first intellectual considerations of why things are placed with the dead and so although Brown doesn't use the word grave goods it captures very poetically and vividly some of the motivations that might lie behind the inclusion of objects in variables which I think I'm still going to find it hard to trump in the final volume of course when we deal with antiquarianism we're dealing with a set of ideas about those objects which immediately leaps to ideas about identity so when we're dealing with these are quite to my favourite antiquarians and Mortimer of course Greenwell who worked in the area that I know best in Storkshire their curiosity about those grave goods lies not so much in the objects and material types although they are writing about those of course as to what they tell us about the racial history of Britain and there's quite a difference of opinion being debated between these two authors who were of course considerable rivals and they did finally collaborate on Dane's grave excavations together but through the contrast of comparison of their grave goods they have quite different ideas about how to interpret them in terms of racial identity so for Mortimer he was quite uncomplicated about it particularly in relation to the Iron Age material you have a new technology, the chariots you have a new way of working metal iron working you have new art styles which are being more complicated and sophisticated this to him indicates that a new state of civilization a more progressive and accomplished people invading East Yorkshire from the continent but both of these authors are using craniology in relation to that material culture and that puzzles them because when they excavate Dane graves they don't find any weapons and to both of them that poses a real puzzle as to whether this is actually an invading race Greenwell is very influenced by the work of the Reverend Morr Coll who persuades him that there are no weapons in these graves this is a peaceable people this is a settled population and he therefore uses his craniology reports to argue that you are looking at the results of him breeding between the ethnic and bronze age populations and what you are seeing is the result of that fusion expressed both in the burial rites the human remains and the material culture he obviously overlooked some of Wright's thoughts in those craniology reports but for Mortimer Carlson's report to talk about this much more racially pure group and he links that to the objects like the fibulae styles and the pottery, the metalwork and by the end of his life in 1911 he's decided that even even these encumers are not particularly impressive so waves and strays from across the ocean bringing in these new ideologies about burial alongside those grave groups Of course by the time we get to 1930s, 1940s we've moved away from using the word race but there is an implicit idea that new burial rites new suits of grave groups are allied to a new people a wessex cultural beacofoak and here we can see Piggit's ideas about this delight of our barric finary which unless led them to conquer this uninteresting and un-enterprising substratum so we've still got this alliance between objects as indicators of people's character and ethnic origin and physical origin and the way in which they're expressing themselves in death seen as very much an expression of their life and we might think we've moved away from that and I'm quite glad he's not here tonight but of course one of our tasks is to think critically about our third partner in the project British Museum and how we're telling that story to the public and so I went around the labels and this is what we will read in those labels and of course Neil's not so responsible for this nor is Julia Farley, our lovely iron age curator these are labels that were written some time ago but still within their the way in which they're describing those objects those narratives that if we're not going to talk about ethnic identity or race we can at least talk about status that the notion is that there is an uncomplicated relationship here between what people place for the dead and their identity in life, so rich burials are signs of high status elite identity, importance and they are ways in which what we look at Duncan's peaks we can spot moments when society becomes more complicated, more stratified and that that is expressed in death through the things one is buried with now there are more subtle stories of course to tell and I always feel I'm trading very much hopefully very respectfully in footsteps of me instead when I'm in the British Museum and in my research in the field and some of I think more subtle interpretations here belong to him so when he's talking about Mill Hill Deal he is trying to unpick what is that crown about on that scum it's a sign of leadership but it's spiritual it's a military, it's a political so he's complicating some of those ideas so there is subtlety there but arguably our job is to bring more subtlety out of those interpretations of the objects themselves and to remember you know I was a student of Mike Parker Pearson's at Sheffield University and he, this was how he started his funerary archaeology courses with that quote from Edmund Leach reminding us that we are dealing with death these people have died this is a funeral and because it may be willed by the deceased but it is orchestrated by the living this is a political moment a moment when identity changes a moment when people reorganise their own position in society and when they are dealing with the emotions around death and loss of itself so the notion that some of these things might be gifts some of it to do with the funerary performance itself and some of the emotions that surround that that is something that we want to bring out more richly in our accounts so I'm going to now just discuss a few themes that we're going to be working with in terms of looking again at some of those object classes what do the dead need? when they are recently deceased they still have a bond with us it is very physical they need us to do things for them they need us to perhaps wash them, dress them and that might include fine clothing or favourite clothing or new clothing or old clothing we might prepare their bodies in various ways with cosmetics we might pluck their hair we might cut off our own hair and layer it in the grave we've got a lovely example that I think at the Aylesbury Arch and we need to perhaps wrap the body or contain it in a coffee or cremate it and put it in a pot or a bowl and so some of the grave goods we are interpreting in our burials in these jorkshawe, in the iron age burials we find broaches behind the head or by the knees or the heels these aren't objects born on a cloak as in life, they are wrapping a shroud around the body and so we need to see them as part and they are well beyond objects that were fond tokens of these people but in this context they are also being used to perform a few functions so we are trying to think about that moment of tenderness and care and going concerned that the dead require from the living because this is the last set of bonds that you will perform for them and if you really do think the dead have agency and there is an eye after life and they can come back and warn you then those acts really matter to you from that other side of the spiritual realm and to do that we are also drawing on some anthropology and sociology about funerary rights and about dressing the dead so this is a quote from a lovely article by Catherine Harper that talks about the moment when she is encouraged to bring her father's glasses to put them on him and the quote she has from one of our archaeological interviews is about the fact that she is back on somebody who habitually more than humanises the dead makes them look like themselves so you mustn't forget that part of what you are orchestrating here is a narrative and a story about that individual which is part of the benefit of the mourners themselves one of the articles that continues to inspire is Joanna Brooks, lovely asked about the ties that bind so if we are dealing with beautifully rich burials like the White Horse Hill Cairn Early Bronze Age Burial of Dartmoor Cremation wrapped in a bare skin with a nettle fibre garment high fringe a delicate bracelet woven from cattle hair studded with tin beads the basket tree, the ear loops the necklace of composite objects what we can see in this range of brave goods is not what we might have otherwise passed in a very fancy elite burial but a burial that encapsulates the wealth of that community the relationships this woman might have embodied and the many donations of things or substances that made her what she wants and so we are trying to pull out of even though some of those more mundane objects that scale of relationships which might be brought to bear at the moment to that send off that final farewell and part of this bringing of things to the dead some of these gifts or personal possessions may well be that comfort the dead has been given that they are still part of a community and this is another quote from Harper's article about why people in contemporary society put photographs of the living around the dead and the sense that that company that is provided for the deceased reminds them of the living connections the memories that they'll still be held in so that sense of people gifting things around our prehistoric bodies may well be part of that reassurance that they are still part of that community part of that network yet we are not going to dismiss the idea that some of our burials tell very personal stories through those objects about the life that somebody has lived this is chariot of burial 1 from Wetwine Slack where we have a disassembled chariot lovely set of spearheads and a beautiful iron age sword and this is an individual who has certainly had a colourful life the scar you can see on the bottom left has a slice taken off it with an iron age sword with that together but that is a real hole in his head he lived with that for many years beyond the injury and so this is an individual who's probably quite changed by that accident probably thought of as quite extraordinary there's no sign of infection there extraordinary testimony to the medical care and perhaps his send-off is an absolutely fitting martial kind of send-off for this individual that is in keeping with the life and the experiences this person has lived but sometimes we see objects that are in the true piece together for the funeral itself is another chariot burial this time from West Yorkshire an outlier from the main tradition probably an area of Yorkshire where they're not completely familiar with how to do this and here we have a vehicle that is literally put together out of old bits so the wheels are old, they're a mismatched pair they've seen a lot of action trundling around but they don't belong together they're a different kind of circumference one is decorated and one is not so somebody has taken one wheel somebody has bought another wheel nobody has any terrets so they make those fresh, they're complete shams they're little thin bits of bronze around a clay core and the excavators say if we've done more then wheel this to the grave side we'll have fallen apart so some things are freshly made for the debt and presumably this is because probably this individual was from Holden S and said when I go give me a chariot burial and they're improvising a little chariot for hand and making new ones deceased but the crafting of new things for the debt is a common theme that's coming out of many of our examples and at that moment of crafting something new of course is redolent with the symbolism of new life of new possibilities and perhaps even new identity he may not be a chariot driver this may be a complete fiction but at the moment of debt he's being constructed with this glorious send-off when people give gifts of course they may be settling old debts but they may also be creating new obligations reminding us of that strategic captain of the debt themselves and one of the things we're coming across in our accounts of some of those freshly made objects is that we see sloppy or imperfect objects hastily made and often when we read the account of that it's well, you know, the debt won't notice it's just for the few who can get away with something not being quite right and second rate perhaps and none functional and that may well be the case but in talking to our colleagues in other domains such as mortuary care and palliative care for the debt we think that has a deeper meaning which I'll come to in a moment so one of the things we're interested in is the way in which you use the barrier itself to create a powerful ancestor figure as Richard Jenkins reminds us and I've seen him death conceal the picture post-mortem revision of identity so when we see our glories late iron age burials constructing concepts of kingship and authority is this something that's individual and lived through in life or is death itself the moment when those new ideas are powerfully repeated to the community and many years ago Rinsall pointed out that it's a curious thing when you get objects that are implying some sense of agency in the afterlife so when you have both the means of making fire and the materials to do so or as our Lord and John Hunter point out daggers and wet stones which imply a sense of the resharpening of a blade that has yet to come so we can look to our grave goods for some insight into whether there was a concept of agency in the afterlife and roles that had yet to be fulfilled the dead share in that funeral performance itself and one of the other themes our project is the importance of food within the graves for example he instead draws a distinction in his volume between grave goods which he argues are personal possessions found on the body and grave gifts which for him basically means joint meat and normally that's the left humerus of lamb and leg of lamb in a pot from the average burial but for chariot burials and sword burials it's pork and I was particularly struck when viewing the wonderful volume on the edge by this quote about 19th century Cheshire where there is a a count of a special cake that people eat at awake and it's wrapped in rosary and that rosary is either tossed into the grave or actually placed in a coffin itself so something fragrant that's been wrapped around something you consume but it's part of what the positive is given to the dead and part of it is consumed by the mourners so that notion of sharing in the performance is important and one of the colleagues we've been talking to in anongo conversation between our projects is Carina Croucher from Bradford University and on her continuing bonds project she's been working with pallidative care teams to look at the way in which they negotiate death with families and people who are aware that they are going to die and one of the things that's coming out of her work is the importance of crafting as a process that happens in the last few weeks of life or things that are made in memory of the recently deceased and Alex Gibson had argued quite some time ago that the little pots that we sometimes find in early Bronze Age burials the pigming pots are particularly poorly made some of them and we are wondering whether there's not something going on here in terms of some of those sloppily made objects where we're looking at objects either made by the mourners that are deliberately badly made as signs of grief perhaps and your gift to the dead expresses that confusion and kind of mourning period or perhaps they are literally made by the dead themselves as a powerful thing to engaging in those last few weeks of life some of our other burials have quite a different feel to them and this is particularly the case in some of my weapons burials in St Yorkshire but also in Kent and in Dorset where we find quite a fury, anger and drama at the grace on it so we find sword bent or snapped or folded shields as in the Mill Hill deal folded in half we can imagine a wood splintering and cracking almost famous in East Yorkshire the speared burials where we can tell from the fill of the grave that a cohort of young people probably I would imagine are stood around the grave casting spears into the grave fill as it goes in and some of the spearheads as at guards on station 10 end up in the corpse itself stick out of the grave dramatically and we know that those shafts are not pulled out so the spears end up like bristles or spines poking out of the aerial man and this is I think what we could see as a kind of a marshal send off a gun salute for usually a young man who has died at an timely age and of course we know that grief and anger are part of the emotions we often experience in the morning process and for a lovely kind of discussion of that I'm given that one of the audiences we're working with our school-age children we've been using a monster calls by Patrick Ness where destruction violence and grief are works to it very visually kind of in a tentatively engaging way so these are things we want to bring out from our dramatic case studies as well that drama, that violence that can happen to objects almost as a surrogate to the body itself Sometimes death is appalling but it's devastating we're dealing with agricultural communities by and large and when that's a double death as in case six a woman who dies in childbirth that's especially atrocious for them the loss of two lives and so with some of our other smaller objects we're trying to think of the way in which those bad deaths might be dealt with through special kinds of objects so substances like jet and amber which and Woodward has long argued have very special powers and properties that are probably drawn on both symbolically and probably real magical practice in the early Bronze Age that the wrapping of a body or surrounding it with amulets like this little bronze disc usually found as a fertility charm on the continent but here perhaps on a garment or parts of the wrapping around the head that these might be ways in which you use objects to negotiate a particularly difficult death and as Blocker and Parry reminds us there's nothing you fear more than a revenant so when death is difficult objects are part of how you negotiate how you charm the deceased into taking the next step into the other world and sometimes the dead don't go alone this is the so-called simple couple excavated by Brewster back in the 1980s of a man a woman buried together staged through the wrist and the elbow and for Tony Brewster what he thought he was seeing was evidence of an illicit affair because the woman has once again died around the time of childbirth but another way of reading this is that we're seeing the creation in death of an eternal couple we don't often use ideas about assisted suicide or people deciding to part together in the world but if this man has lost his wife and child or parent child perhaps he decides that they shouldn't go alone into that afterlife we're perhaps more familiar with thinking about animals in burials as perhaps companions for the dead and this was the little set of notes that I found in my own copy of Mortoners 1905 article drawing my attention to the fact that dogs heads are found within thin burials and the author, I don't know who they were simply wrote in brackets souls are not lost with dogs and that sense that there are some vulnerable dead who need companionship whether that's an animal or whether that's a special object or photos and drums companionship helping hands as my Egyptology colleagues call it that's another theme we're going to be looking for so I just want to close with a bit of a local story in the BBC Manchester they reported on a set of incidents that happened in Bolton crematorium most notoriously coconuts had been slicked into a coffin and when it had gone into the crematorium it exploded very violently in real fear amongst the crematorium assistants and so they issued a set of guidance asking people to refrain from placing the following items into the coffin which included a list that you can see there golf clubs with ski mobile phones television handsets love letters, e-cigarettes bikers lent them to parents and said well of course we couldn't let them put those in I don't see any reason why not but maybe they have a combustible property I don't know but what Fascinated Us is a very good team that's nice to us the urge to bury things with the dead is still there with us and the crematorium team said people have got so sneaky they know we go through the coffin they're slitting the lining and stuffing it into the lining of the coffin and so these things are still causing problems for the mortuary care teams but prehistory tells us this is a very human sentiment libations for the dead things that give them pleasure elections messages that you never got to deliver these are all things we think we can see in our objects of course my classical colleagues would point also to the tokens the symbols like the oval as a way of earning a passage if you think of death as a journey into the afterlife you may need a coin or a token to earn passage into that afterlife we're not dealing with an era until a very latest lineage but we've only been looking to see whether we have any symbols or equivalents and one of my lovely undergraduate students just to end our piece found that one of the people she interviewed at the crematorium had slipped a £20 note in somebody's breast pocket and when she asked him why he'd done it he said it's a latch lifter he said what? to bribe, he said Peter, the gate he said get in and so this complete Manchester club mentality give the doorman a bribe but he was using a term a latch lifter, this is very ancient I doubt he knew what a latch was so we hope that our project has things to teach ourselves about what we do and that from prehistory we gain those insights through that conversation between past and present


A viral Twitter thread about a woman's experience of sexual trafficking during a 2015 trip to Florida has been turned into a movie called Zola. Inspired by Azia Zola, King's 148th tweet thread about a subsequent story in Rolling Stone magazine about her experience, the drama follows Detroit actress and exotic dancer Zola, whose customer Stefani convinces her to travel to Florida for a weekend. But the trips and turns sinister when Zola realizes that they are traveling with a pimp who has other intentions. King's account of the trip whose details she later said she embellished, lit up on social media, trending under the hashtag The Story. Some of those she named in the tweet have disagreed with her depiction of what happened but Zola would anyway still be released on June 30th. Hello, hope you enjoyed the news. Please do subscribe to our YouTube channel and don't forget to hit the notification button so you get notified about fresh news updates.