All right, I think we can get started. Thanks everyone for showing up for the last talk of the day. I expected it to be half empty in here and everyone to be tired. So thanks for still coming. So if your career in software development resembles mine in any way at all, you've probably found one thing to be constant over everything else. There's always more work to do. No matter how much you try, no matter how long you work, there's always something else you can do today, tomorrow, next week. For me, like I said, this has definitely been the case. I work on the Google Cloud Client Libraries team, and we maintain hundreds of different packages. To make this problem worse, they aren't even all node packages. We maintain eight different languages. Now luckily, no one on the team is expected to know all eight of these languages, but almost all of us know more than one, and we still have to maintain all of these things. So that only helps the problem a little bit. What we started to realize is that we needed help, and that's when the bots came to save us. I say the bots came to save us, but I'm obviously speaking poetically. They didn't come to save us, and our bots aren't all that smart, so I wouldn't expect them to be our saviors. I mean, they're helpful, but they tend to be good at just doing a single thing very well. Before we get further into this talk, I wanted to discuss what is a bot? What does that mean in the terms of software development? When I think about robots, I immediately think of an automotive assembly line, and these big arms that replace the job of humans from decades before. But we really don't mean this when we say bots in technology. We're not usually talking about a physical robot of any kind, and we're not even talking about a robots.txt. Robots.txts are crawled by web crawlers and are fairly similar to the bots we're referring to, but they're a little different as well. What I usually mean when I say the word bots is something that resembles this. I mean a script that runs as a result of an action, a trigger from something external, that might be a timer, that might be a pull request, and as a response to this event, some code runs. Bots aren't good at all things, of course. As I said, they're usually good at repetitive work, things that are scoped, one single thing, but they're very good at that one thing. Particularly, they're good at things that don't require intuition or any sort of debugging. So the sort of action that can be blindly followed with a strict process. And this isn't necessarily a bad thing. Because it turns out humans are really bad at being robots. Multiple studies show that when humans in a counter-repeated processes, we fatigue, we make mistakes, we miss steps. And so it's good if we can use something that's good at following rote rules instead of ourselves. I think it should be our goal to eliminate as many of those sorts of tasks as possible so we can focus on the work that requires human intuition and generally brings joy to developers. And while most of us use bots, I think it's true that the majority of software developers haven't written a bot. With any hope by the end of this talk, a lot of the mystery around that will be removed. So to frame this, I wanna talk a bit about levels of automation. The SAE, Society of Automotive Engineers, has a standard for self-driving cars where they separate the levels that they are automated, the amount the system does work. So they separate those out so we can have an understanding of the advancement and sort of risk involved. This will help us sort of understand things and it will allow us to start with simpler bots and get to more complex ones as I talk. So this is the chart they use. I'm not going to try to describe it exactly, but at level zero, it's your typical car, the ones that have been around forever. The human being does everything. Eventually you get to level five where the machine does everything. In theory, you don't need a human being. It is entirely unscoped, meaning it doesn't just have a list of tasks it can do, it can do infinite tasks, anything at all. This is the fully self-driving car. So if we take that and apply it to bots, we get this chart. We're at level one, we have things that are automated a little bit, sort of at the level of a script or a tool. And eventually again we get to level five where the machine does everything. You can see at each level of this chart one more thing is taken over by the system. That's the bolded bit. I'm not going to try to describe this much further here. I think it'll be easier as we go into examples. So at level one, put simply, our goal is to automate portions of our workflow. Not necessarily make a bot do all the work, but take away the parts where it's easy to make small little mistakes. As a human being, you're going to discover the work.  But the work itself will be automated. So let's put up an example. We have a package and our goal is to release this. But releasing takes multiple actions. It might involve tagging a branch, updating a release number, publishing to NPM, maybe deploying docs, et cetera. So how do we fix that? Well, we can write a script. Script can do all of those things and we can click a button. This might not sound entirely like a bot yet. Bots, we don't tend to think of as being a thing where we just execute a script locally, but this is the most basic bot. The deployment environment is your machine. It does a task for you. The only thing that's a bit odd is because at level one we're still triggering and assisting the system, it doesn't feel all that automated. And then we move on to level two. The best way to describe this is that we can automate the discovery now as well as the work. But we're still, as human beings, going to be responsible for supervising the bot. We're not going to trust it to operate unmonitored. Representative tasks for that would be that script we authored previously could be forgotten to be run. And it would be good to know if that happens. If we have some release ready to go, let's say we've updated the release number within package.json and we haven't published yet. It would be cool if we had some sort of monitoring to let us know about that, so we don't just let it sit stale forever. And when we start in the level three, this is where I think you start to really see them as very useful bots. At this point, we let the bot start doing work for us. We have to supervise it a little bit, probably check in on it. But for the most part, it's fully starting to self monitor. And we're not going to have to do a lot of intervention ourselves. An example of how that might manifest is we have issues in our repository that goes stale. So we all have repositories that we have to work in and issues get assigned to developers on the team. But occasionally people on the team become overloaded or that individual on the team maybe isn't the subject matter expert for that. So they're stalling out. So we can implement something that juggled these issues around and could assign them to a different team member to see if that would help us get traction. Another example you might see here is something like a CLA bot, maybe where you can notice that someone on your team doesn't have CLA's and you could sort of walk through that. It's going to require very limited monitoring. The monitoring at that point is mostly in the fact that nothing's going to get merged without a human. But the bot can still go through that entire interaction with a new contributor. And then we get to level four when things get a bit more advanced. We don't really have to supervise any more at all. The system handles its own fallback. When errors happen, it knows how to self recover. Maybe if it has an error it can't recover from, it opens a bug for you. So what does an example like this start to look like? Sometimes it turns out that in our repositories we have branches that get created for PRs and contributors forget to delete them. And this starts to make things get a bit bloaty and hard to see what's going on. So maybe we could write a bot that deletes them. And I feel like this is a point to mention that as you go through the levels, risk starts to increase also. This is a rather risky thing to do. What if those branches are needed and you made a mistake in this bot? This is where I mean to say it's not really supervised anymore. It starts to take actions that would be hard to recover from. So other bots in this category are things that look like merging on green to master where maybe you reviewed it and located it earlier but someone merged something else, then the CI passed and it gets merged in. And that could be rather risky. There are a lot of bots in this category and the example we'll use later falls into this level four. And finally, we get to level five. I think at level five, the easiest way to describe it is the robot starts to become your own boss. Because unlike the previous one, it's now unscoped. It no longer has a question and a solution. It just responds to all questions and all solutions. And I think you'll find the science fiction has taught us that unscoping bots can be a rather dangerous thing. I don't know that I would really want this happening in my repository. I would say we avoid doing this all together, if at all possible. And after all, human beings are good at these sorts of tasks anyway and we usually want intuition. So this probably isn't where we want to look for bots. To sort of tie back to automotive, they're finding the same problem. In automotive driverless cars, getting to level five is going to be very difficult because it means the automation needs to understand new scenarios it hasn't seen before. And that's a pretty giant jump from training on existing scenarios. So at this point though, I think we should talk about writing bots and not me just sort of giving you quick examples. And you probably thought maybe we could just write a bot to write the bots. Let's go back to the previous step. We probably don't want to do that, right? If we find a way to have bots write bots, we've probably reached century computing. And then you end up with this weird problem of who watches the watcher. Eventually realizes turtles all the way down and you're probably just going to have to accept that we're doing this ourselves. So while we can't use a bot to do this for us, we can leverage a series of frameworks. And our team found one that we liked a lot called ProBot. This is good because most of us don't want to spend our time authoring bots. The bots are a means to an end. They're not the solution itself. They're not our marketing. And so being able to leverage other open source products mean we can get back to our product and not just being bot authors. ProBot integrates really well with GitHub. It's authored by a GitHub engineer. And it allows us to trigger events in the form of small node apps based on a GitHub context, many different GitHub events. The nice thing too is they have a variety of samples we can use to sort of inspire ourselves and understand what to do. The documentation is fairly good. And so that's what we decided to go with. So the first thing we're going to want to do is think about the scenario we want to solve and try to scope that to a problem that is solvable by a bot and no longer requires a human. So a simple question that we might ask yourself is could we have renovate PRs, PRs from the renovate bot automatically run CI for us and not wait for an engineer on the team to go tell the CI system to run? The reason this is important is systems like Travis Circle and the internal CI we use, they restrict which contributors can kick off builds. And this is important. Most build systems have secrets. And if any random person on the internet can run a build, they can modify those files and they can expose secrets. So we don't want to allow that to just happen. It needs to be a trusted contributor of the repository of the project. But renovate isn't really a contributor. It's a thing we use, it's a thing we trust, but it's not part of the GitHub org. And so we could probably write a bot to do this. And that seems like a small enough size and something direct. When renovate creates a PR and we detect that it's the author, we run CI. The next thing we need to figure out is what sort of events do we need to trigger this on? We could try to trigger on all possible events, but that's probably going to mean it runs too much. So we might want to trigger on initial PR, maybe on updates to the PR, maybe on the creation of an issue. That's probably not relevant in this exact example, but it's a common one. There are dozens of different events you can trigger on, but for me these four are most often the ones you end up using. And the next decision you get to make is are bots going to alert or change your system? And this again goes back to risk. If a system only ever alerts you of a problem, it's generally not that risky. In the case of something like a CLA bot or maybe a Linting bot, it's likely to just leave a comment on the PR.  On the other hand, if we make changes that run the build system, merge, publish, they become more risky. These are the sort of things that causes incidents. And so you need to decide how much risk you're willing to take on in this instance. So for the case of this bot, we're going to likely add a label to our repository that says it's safe to run CI. And so this looks a little more like a change. And so that's a little bit more risk, but we can't get the value without that. So let's get around to building it. Probot comes with this quick start we can run via NPX and it's a pretty reasonable place to start if you've never written a bot before. It's going to populate you a node project that has most of the templating after asking you some simple questions. We didn't use this exactly because we found out that we wanted to do templating on top of Probot. And so we recently added our own bot generator that does basically the same thing. There's a few less questions because we can make a lot of assumptions. For instance, all the authors are Google and so that makes that a little simpler. But this also allowed us to do things like template our read-me's and have consistent style across all of our samples and have similar targets inside package at JSON. Like I said, at the end of the day, this is just another node package. All the bot system does is runs a method when an event happens. It's a pretty straightforward application and looks like a lot of things you've used before. And as a very bare minimum set of dependencies, we're going to use something from OctaKit to interact with Git. We're going to use Probot. In our case, we use a thing called GCFutils because we leverage Google Cloud Functions for this. And we have a package called GCFutils we wrote to let us do that. So diving a bit deeper into source, I wanted to look at the code that isn't just boilerplate. Most of this will be, you'll probably never edit it. But inside of one of the TS files, you're going to find a function that takes an application and on a list of events does some action. In this case, we have a few different triggers that we're going to go on. If a PR is opened, reopened or synchronized, that's a PR update, we want to run an event. These are all possible options for renovate when it comes through. But the bot we write is pretty simple. We check the pull requests user login and if that user login matches renovate, we can add a label to the repository. Bots aren't necessarily all that complicated. A lot of times they're simple actions but the difficulty of this part of the bot doesn't really tell you the value. This one bot has saved hundreds of hours for our development team from having to go into these issues and tell them to run CI. So how do you set up your environment to do these bots, to offer these bots locally? This is pretty GitHub centric in the way I describe it but it's likely worth noting there's nothing GitHub specific about what we're doing here. You could change those events to not be GitHub events. You could use Probot and send it web hooks from somewhere else, all possibilities. So the first thing we do to support local development is start a proxy. This is so that way we can use our local development system as the target of the web hook that GitHub provides. And there's a service called SME we can use. All you have to do to use this particular proxy is go to SME.io, click a button and it will give you a slug URL that you can then use to route your issues to, your events from GitHub too. So we start by running a proxy once we get that slug URL and this sets everything up for us. I should mention it's possible you don't even need to run this step but we've found environments that if you skip this it might not properly configure. And so you run it once.  And the next thing you do is you run NPM start. Like I said, it's basically just a regular node package once you use Probot and it will direct you to go to port 3000 of your machine. And this is that way we can go ahead and set up the GitHub app. You'll be presented with a screen that looks like this where you have to register a GitHub app. You'll go through the GitHub apps creation process. We'll give it a name. We'll configure permissions. Once we get around to configuring permissions things start to get a little bit harder to do because we have to ask ourselves some real questions. What does this bot really have to change about a repository? And in theory we could give it all access but again back to risk. We likely don't wanna do that. So we're going to have to start sort of thinking. In the case of this bot we're going to need right access to the repository because we need to add labels. We're gonna give it permission to mess with pull requests only and that will restrict it from doing anything too crazy. And once we've done that we need to install the bot into the repository. There's a install app button on the screen we're on for permissions. And you'll be presented with a yellow box and where you'll have to review your permissions. So the permissions here are being reviewed are from the previous step. And I point this out because if you don't do this nothing interesting will happen. You'll sit here awhile, it's an easy mistake to make because you think well I've made a bot and I've set permissions but you have to do this step. You also might have to do this step again if you ever change the permissions. And that's a gotcha that's caught me. I haven't given it all the permissions I needed the first time around. And if you forget to do that again it won't trigger on those things until you come and do this. So we click on that link. We can say all right these permissions are safe I'm happy with that.  It's not important. I can make PRs against the branches, whatever. It'll be fine. And I target this repository with new bots. That way I can sort of test drive them before putting them against anything live. So we set that permission up and we can move along to running the bot. To do this we need to set a few environment variables. Every GitHub app comes with an application ID. It comes with the private key. And it comes with a secret for web hooks. These are pretty straightforward to get. The app ID will be at the top of the app page and we can export it to app ID. The web hook secret is a string that you set. So for demonstration purposes in this case it's a ProBot demo. And then we need to configure private keys. At the bottom of the page, there's an area that you can generate new secrets. It'll automatically download a JSON for you. And as long as you put the path to that it'll be able to resolve this for you. So here we show ourselves running npm start. It's forwarding to SME now to localhost 3000. And we're starting to get these post requests coming through. And the post requests are all the result of me opening this PR. I set it as a test repo so you can see that I've updated the read me a bunch and opened and reopened pull request. And then we can go over to SME and start to look into what events we're getting. If we expand one of those pull requests we'll see the JSON payload and what it looks like on a live repository. You get a better idea of what information our bot's receiving and how to respond to it. So this is handy for live debugging and just ad hoc testing. But it's also useful for then taking these payloads and turning them into unit tests that are repeatable. And so that's where this tends to be most useful is you can ad hoc test how it works and you can capture that and turn that into a test you can run over and over again and avoid regressing your bot. So what is the deployment stack for that look like? Now that you can run it locally how do we get that into somewhere that's not running on our development machine? We use a variety of services. Like I said we put this on Google Cloud Functions. We ultimately use storage, a thing called KMS Key Management Service. So let's talk about a bit of those components. The most important bit is Google Cloud Functions. We started on this just as a call out right away. At the time we started this GitHub actions didn't exist and at this time if we started this again that might have been an approach we looked into. But we already started this for Google Cloud Functions and so it doesn't really make much sense at this point for us to go back. Google Cloud Functions take a web event any sort of HTTP trigger and they can start executing. So they're these little on-demand actions which is a really good fit for a bot. They tend to be a good fit for anything that doesn't have a lot of state management and that's not being called very frequently. And most bots aren't. They're intermittently called maybe just during business hours and so this is a good application for that. And there's an existing Google Cloud Function Handler that ProBot provides. If you'd like to use this you can install it from them. We also wanted to use the thing called KMS Key Management Service. And so the idea here was that we didn't wanna store any of the secrets in the Cloud Function itself. There's a potential security risk in using environment variables in the bot as well just like there would be for a CI system. And so instead of using environment variables we can inject these things through the KMS system which ultimately stores them on Google Cloud Storage and then they're fetched as they're needed and then immediately piped into the commands. So they're never sourced in environment variable. It would be more difficult for someone to capture those things. And so the utility that's released by ProBot doesn't support this so we ended up writing our own. It is a rather simple boot scrapper so that wasn't too much work. But if this sounds interesting to you that you would wanna use Cloud Functions and some of these more advanced features feel free to reach out to me or come visit any of the Google booth. I'd like to talk about it. We haven't yet released this to people. It's only in our repository but if there was value it's something we could consider open sourcing further. So this is the version we use. Like I said it's a simple package in our repository. It is under active development but if this interests you please talk to me further. We also use a system called Google Cloud Build and this is what deploys our bots. This allows us to use the secrets that we're storing as well as the deployment pipeline, no developer needs to manage the publishing it just self publishes as we need. So that's good for us. But let's step away from that a bit and get out of some of the Google specifics and just talk about if you were to publish a single bot to something like Cloud Functions what would that look like? It's going to look again like a lot of node apps you've written before. We're gonna have a compilation step. All of our bots are typescripts most of our code base in fact is. We're going to make a target directory and copy some things over to it. And that's the build step. Technically this target part isn't necessary but it is a bit of a safety. It means that when we go to deploy we don't deploy anything unnecessary. We're only going to deploy the things we most care about for the bot not random artifacts that happen to be in the repository. For publishing we provide a function name and Google Cloud comes with a tool called gcloud and we can use that to upload a function once we provide a directory. Through here we're going to provide it to use all the K and the secrets for us. It's gonna go through and upload it for us through gcloud. And that can be done without Cloud Build. The reason we use Cloud Build ultimately is we have more than one bot and so it's nice to have a centralized system for that and a pattern we can follow. So I hope this has helped you understand a bit of how we do bots at least for Google Cloud client libraries and has inspired you to embrace using bots to free your team from a lot of gardening and allow you to do more meaningful work. I would say that any task that's repeated often is a good candidate for bots and virtually all projects can benefit from using them. I'd also like to mention that all of our bots are open sourced. They're on GitHub but they can be looked at. This is the repository they exist at. There's a variety of instances of them and most all of the examples I talked about are bots that exist that we are using today. And I also wanted to take a moment to thank the others that contributed to this. I am certainly not the only one that has worked on this project. A lot of people have. I just wanted to take a moment to thank them all for their efforts. So thank you all for having me.


All righty, can you hear me all right? So I'm gonna use this screen. Yeah, so thanks so much for the invite. It's a great pleasure. I think it's my first talk at FossApp, which is particularly exciting. So we've taken a bit of a detour over the past few years. So I've got the word evolution in the title. And I hope to convince you all that thinking about not just how the retina works, but how different retinas work and why is instructive. I'm going to try to link a few posters that we've brought in this talk, some of which are today and tomorrow, but some of which were yesterday and the day before, but worry or not, they're online. So if you zonk out during the talk and you want to spend your time productively, nonetheless, do click around those. Okay, so does this work? No, don't worry, I shall use the key. Okay, so don't worry. Let's put it in here.  We have a huge amount of investment of neuronal real estate and computation in the encoding of space and time. And once you've got those two, you get yourself a beautiful gray scare representation of the visual world, which is basically 95% there. And then we sprinkle in the color, a little bit like spice. And then it's a little bit nicer, but honestly, who cares? So, and I think that's not how it works. I think that's a fundamentally misguided idea and we need to get rid of it. So what I'm hoping to try to convince you in the next few minutes is three things. So in the stew that is red, the coating, which looks like this, the color is not the seasoning, it is the meat and the potatoes. I'm gonna try to convince you that different cone circuits and that in different behaviors, and that we should stop thinking of the ability to use multiple cones just to give us a perception of color, we should think of it as different inputs to the same system, which is designed to drive different kind of circuits and behaviors. And finally, I think by looking across species, we've stumbled across what you might call a principle of how color works. And the idea is that color is encoded in the on circuits and the off circuits serve as a universal achromatic reference. So, but this, let me jump to the question that you've all traveled here to get addressed. Did dinosaurs see color? And yes, they did. Why so sure? Well, here's a bunch of animals, all vertebrates, representing the entire lineage starting from the Cambrian and I've taken the liberty of annotating all the animals that can see color. And the dinosaurs are some of those animals, therefore the dinosaurs saw color. But we can actually go a little bit more sophisticated than this. So, where does color come from? Well, you need more than one photoreceptor. Most of these animals have that. But what you can do with these photoreceptors, and this I think is really elegant, is you can link them across animals. So for example, what we call the green cone in the mouse, or the long wavelength cone in the primate, LWS, is homologous to the single cone, the red single cone in the bird in reptiles, in amphibians, in fish, even in sharks, and down to the lump ray. And that means there's a common ancestor before any of that evolved that also had this red cone. And we can do the same thing for the UV cone. Well, in humans we call it blue, but it is the ancestral UV cone. And it's the same as the one that's in the mouse, it's the same that's in the one in the fish, it's the same as the one in the lump ray, and it's also old. And you might ask, how old? Well, we're thinking about 800 million years. So, Cambrian explosion, first vertebrates, 550. First photoreceptor, 800. First absence, 800. They immediately diversified and they never went back. And the only major change from this ancestral state to what we might have, for example, in the fish these days, is that this R-aged component here turned into the rod and the green photoreceptor before the shark split off, but after the lump ray split off. So the lump rays have a slightly different solution. They're still rods, they're just ever so slightly different. So photoreceptors are very nicely linkable. But that also means that all these clever little animals that do clever processing are built from the same color source. And that color source must have been present in the eyes that didn't have lenses yet and that didn't have a cornea yet. And basically that weren't really used for spatial vision at all. So where does vision come from? Well, you need a photoreceptor. And that's responsive to light from any direction. And then the first thing that happens, other than it gets more sensitive over time, evolutionary time, is you start to screen the photoreceptor on one side. And that makes it directional. And already you've got directional vision. You don't have spatial vision, but you have directional vision. And that's useful. But the next thing that happens is that these photoreceptors start to clump together and you get invaginations. And as soon as you've got something like this, it's basically a lensless eye. It gives you a spatial image. It's a terrible image, but it gives you an image. And you can use it to navigate around the world. So the sort of things that you might be able to use, and oh, I should obviously point out that the color is in here all this time. So you can certainly use it for circadian function because, of course, the world looks different. The wavelengths composition in the world changes as a function of a circadian day.  The other thing you can use it for, vision evolved in the water, not on land, is you can use it as a depth scorch.  So if you have a circuit that compares, say, UV light with long wavelength light, the stronger it's driven by the long wavelength light, you're deeper in the water. That is critical information if you're an animal trying to make it. And there's actually a beautiful demonstration of how this works without an eye. So this is a platinaris. It's a lava. So think of it as a little worm. It doesn't have an eye. These are not eyes. It has two photoreceptors. One is green and one is UV. They connect it antagonistically. And if you play with this circuit, you can make these animals go up and down in the water column. So this is an animal that has color vision. It uses it for depth, but it doesn't have an eye. So clearly, you can use color to do stuff that you don't need an eye yet. But of course, we do have an eye. So what do you need in order to go from here to an eye? Well, the first thing you need is you need a corner and a lens. So you start to get a focused and under-focused image, but at least it's a bit better. Spatial vision improves. And with this sort of thing, you can navigate around the world. You can stop bumping into stones and things. But what you can also do is you can already use the color circuits, if they exist, to tell distance. And that's a very neat trick that works beautifully underwater. Light gets increasingly monochromatic with distance, just because light gets absorbed in a wavelength dependent manner. And that means that if there is an object that reflects in a sexually dependent manner, so it's colorful, and you see it as colorful, it cannot be far away, because it would be monochromatic. So if something underwater is colorful, it is near you. If it is not colorful, it could still be near you. But at least you can use the property of colorfulness as a measure of distance. And that will work, of course, with a spatially resolved image like this, but it will also work with an incredibly blurry image. So you can work with color to tell distance, even if your spatial resolution is terrible. And then eventually, we make the eye bigger. We generously afford a bit of space to stick a bit of retina in between the lens and the photoreceptors. And we can start to build the retinas that we all study today. So that wasn't the intention. OK, I'm going to talk over this. It's a video that I stole. So this is what the Cambrian shallows might have looked like. And actually, I'm going to stop. This is too loud. So the idea is that in the Cambrian oceans, life exploded. We started with animals that didn't move around much. The sensory system of those animals were probably quite simple. And very suddenly, invertebrates and vertebrates at the same time evolved sophisticated spatial vision, means of fast locomotion, and centralized nervous systems that could match that information, such that complicated behaviors started to become possible. And the first vertebrates, or they're not even vertebrates yet, they're craniates, but they're just on the verge of becoming vertebrates. They would have looked something like this. I pushed it. It may be the common ancestor to invertebrates, but certainly something like this was the common ancestor to vertebrates. We can see in the fossil record how big they were that they had an eye. And we can guess how they moved around. And what's quite clear is that they were small. We're thinking thumbnail-sized. They must have been agile using all those fins. They were certainly prey species, because the invertebrates had a leg up. They were bigger and they were eating these guys. So at the origin of where all the vertebrates come from, running away from nasty things was fundamental to making it into the next evolutionary step. But also, probably these guys were predators, because zooplankton is older than all this stuff. And of course these guys would have been eating the zooplankton, and you have to hunt that. You have to chase it. So probably they were both prey and predator. And as I was pointing out, they were almost certainly also tetachromat using this complement for the receptors. Now, wouldn't it be lovely to be able to study this guy? Well, that's not going to happen. But what we can do is we can look at the sort of characteristics of this animal and identify animals that are alive today that have a lot of common features. And one of these animals is the zebrafish. And the reason zebrafish, it lives in shallow water. It has pretty much the same photoreceptor complement that we think was around at this time. They hunt. They get hunted. It makes for a very nice comparison. So over the last three years in the lab, we've been trying to understand what color vision or the use of cones is all about in these animals. And I will not go into any detail of what we've really done there. Let's give you sort of a bit of a highlight. So here we've got a zebrafish, we've got our four cones. Notice I've ignored the rod. The reason I've ignored the rod is because we're working on baby zebrafish. The rod isn't finished cooking yet at that age. So there's no rod. We don't need to worry about it. However, when they get old, they have rods. And Pakeshi on his poster, which is coming today, has found the rods by polar cell of the fish. So do have a look at that. So first thing we asked is, so what's up with all these four photoreceptors? How do they respond to different wavelengths of light? We did that in this paper here. And the punchline is basically this, that the red photoreceptor is non-opponent. The UV photoreceptor is essentially non-opponent. There's tiny little bit of this. So this would be the long and the short wavelengths photoreceptors of the manals of the homologous one. In the middle two, they are strongly opponent. And they're strongly opponent to the point that they're balanced, that the depolarizing and the hyperpolarizing lobe are equivalent. And that means that if you go up and down in brightness, they don't respond. They need a chromatic stimulus to be driven. So fundamentally, these are color channels. And these two are grayscale channels. What we did, and we put a lot of effort into this, is actually to quantify just how good these are. It turns out that the red one is nearly optimal in order to do grayscale. And the green one is nearly optimal to do the primary axis that you get from nature in color. I'm not going to justify this here. I'm happy to discuss it later. There's a lot of data in this paper and also in this follow-up here. And then that gives you the other two, which gives you another color channel, perhaps to mop up a little bit of extra color that the green can't miss. And then you get this weird extra second grayscale channel. Why would you need two grayscale channels? And this question, I think, was very nicely addressed by Takeshi here. So what he did in this paper is he put a little aquarium in the sun outside our department. It is sometimes sunny in the UK. You have to be, it happens. And he put a camera and he put a red filter in the time. When you do that, you get a picture like this and it looks exactly like it would look if you stick your own head in the water. You see the underwater visual world in grayscale. If you want rocks, you see water reflections, you see bubbles. That's the sort of thing you need if you want to move around this world and not hit things.  There's a few things to point out. A, you don't see the rocks. The reason you don't see the rocks is because the light scatters so strongly in the water that dominant visual feature is a massive brightness gradient. So Takeshi wears up, that's convenient. But on top of that, you see foreground objects accentuated. You see all these little blobs flying around. Those are zooplankton. There's nothing magic about these zooplankton. It's just they're near and they're small and they have the properties that they scatter UV light better than water. Therefore, they are bright spots that move around. So if you're a little fish interested in eating these things, how convenient to just use the UV channel. It basically does 90% of the feature detection for you. So we wanted to see if that's actually what the fish does. So this is what Nora did here with behavioral experiments. Long story short, you watch the fish, you give it UV light and then yellow light and then UV light and you switch back and forth and you just count when does it attack the food. And that each time does a tick here. And hopefully you can sort of visually pass that it's much better at hunting if you give it UV light and it's terrible at hunting if you don't give it UV light. So that suggests that UV light is being used. It doesn't tell you UV cones are used because it could be a non-UV cone giving that ability. So what she then did is she ablated genetically the UV cones and the behavior is completely toast, okay? So that shows I think really quite directly that the function or one of the key function of the UV photoreceptor in the baby's ever fish is to help it to hunt. But it also shows that we've got a photoreceptor system which is directly responsible for a key behavior that the fish needs in order to survive. We can call this maybe then the breakup tracks is here. It does other things, but this is one of the things it does. So how deep does this go? This is a bunch of cones, great. What's with the rest of the visual system? Well, we do have a lot of data on the reds and then we jump back at this but I want to jump straight into the brain here just to make the point that this is a property that's fairly fundamental I think to how this animal works. So zebrafish of course are popular specifically for the reason that you can look at the brain like this. So here this is just nuclear g-cump in all of the neurons of the zebrafish brain. It's a little microscope trick that Philipp here invented which allows us to get the whole thing. And you get something like 2,000 neurons in the scan like this. So it's quite, you get data quickly.  And she just wanted to see what's the sort of stuff that drives responses in the zebrafish brain. And you can hopefully see here in the video that all of these stimuli drives responses in some of the neurons as you would expect. And just some examples here. So here the white shield motion response so the response when the stripes are moving specifically. Here's an object motion response. Here's an off sale. You get all kinds of stuff. So what Chiara did then here is she color codes in this particular scan whether or not the cell responded to white fields to an off transition or to object motion. So if a cell is white, it responds to a three. If a cell is red, it just responds to the white field motion and so on. And hopefully what you can appreciate is that you get a bit of salt and pepper situation going on. You get quite a lot of red cells here because those are looking directly at the screen. But basically all of these visual properties are represented. And then what Chiara can do is she can go along and genetically kill one cone or the other cone and just see what happens. And I think, I don't want to dwell in this, but I think it's really quite striking just how fundamentally dependent these simple brain responses are on the different cones.  The other two are toast. Well, you get off sales, but not so many. It's basically object motion that's left. If you kill the green cone, everything is still there but the white field motion response is strongly accentuated suggesting that in the native condition the green cones are not there to build it, they have to tune it. And then if you kill the UB cones, the only thing that's left is the off response. So these photoreceptors are directly responsible for these very different key visual encoding properties of the brain. But it goes a little bit further than this. So what we've got here is some data from Aira.  And hopefully you can visually pass that even though it does respond to all of these flashes a little bit, there's a massive shift towards UV. So basically every time the UV one comes on, the whole brain goes and the other colors they just sort of trickle a little bit more. So this is a fish that's UV greedy, it wants UV. But this is not what we see every time. You take the next fish and you might see something like this. This is a fish that's much more nuanced. It responds to all the colors a little bit and in particular, it responds to red. This is, there's nothing magic about these fish. Do you notice fish? You break them, you get them, you stick them under the scope. Sometimes you get a UV fish, sometimes you get a red fish. What's up with that? Yeah? Okay, so there's a beautiful paper that came out a couple of years ago by these guys and what they did is they filmed fish swimming around the dish spontaneously and they would see that sometimes the fish would be like swimming around, be quite keen on exploring the world and then they would stop and start hunting and then they would go, okay, I've hunted enough, let's explore some more. And they would basically switch back between these two kinds of behaviors. And those two behaviors were strongly correlated with switches in the brain state that you could observe at the level of, well, the entire brain response basically. And so what we're currently exploring is whether or not this UV to red thing is not just the fish, this is a UV fish, this is a red fish. Maybe all fish can do both and it's just the stage transition. And while this is not super easy to test because you kind of have to hope for the state transition to happen while you're imaging, most of the time it doesn't, but ever so like sometimes you can see them switch. So I think probably there's something about brain states here. And then of course the obvious interpretation would be that this guy is hungry and this guy is keen to explore the world.  So we then emerge at a picture, perhaps that looks a little bit like this. You've got a very early segregation of very specific kinds of channels already at the output of the photoreceptors. They're still present at the level of the brain. They may be linked to object versus white field motion. And those may in turn be directly represented at the level of brain states, perhaps. Okay, so then how do we get there and what about the rest of the eye? So let's jump back and look at bipolar cells. We published this, so I won't dwell on it, but basically the punchline is that bipolar cells do all of the things that the photoreceptors do plus two extra things. So you can see here, the red guy is conserved, the UV guy is conserved, these two are conserved. And we get a broad channel, which is a bit boring, so I'm not gonna talk about it. And we get an extra opponent channel that's missing from the photoreceptors, okay? So if we don't think this is your optimal color axis, this is a little bit of extra color, why would you bother building a third one? And I should point out that if you count them up, this is the one that's numerically dominant. You get a handful of these guys and quite a lot of these guys, right? So there's clearly something that goes beyond color that this thing does. And I think one clue comes from just considering, and Chiara showed this previously, what happens if you don't focus near, but far underwater. And again, you do the red versus UV trick, right? So if you do red, again, you get the gray scale scene of the visual world as you see it, if you stick your own head in the water. In UV, what you get is you get a bright background because the UV light scatters in the water and gives you basically a fog. And anything that's in front of the fog is the silhouette, dark, and anything that's hidden in the fog, for example, these little fish here that are a little bit further away, the contrast is terrible, whereas you can quite easily see them here. So what would happen if you take the opponent channel, where you get a distance channel? It's very nice, right? The bright things are near, the dark things are far, or vice versa if you do the opponent to the other way around. So it's very tempting to speculate, I think, that this guy, even though it gives a little bit of color information per se, it gives a lot of distance information and how neat to have the bipolar cells tell you how far something is away just because it's either UV dominant or long wavelength dominant. So just a little evolutionary detour, how do you turn the fish into a mouse where you kill those two cones? Right? So maybe, maybe, maybe what we have in the mouse here is that distance channel. And maybe, maybe the mouse uses it a little bit in the same way. And of course the mouse doesn't live in the water, but I would encourage you to look at some of the videos from this beautiful paper here from Thomas Euler's lab, which I think highlights a lot of opportunity for using the same spectral contrast to do some very meaningful contrast computations above the water. And of course then, if you turn the mouse into a primate, this becomes your blue-yellow axis and then you add the midgets on top to get your trichromatic vision, which is not really related in a strong way to what the fish originally had here in the middle. Now, what's next? Gungan cells. We did this a while ago. Punchliners, it's kind of like the bipolar cells, at least if you only look at color. If you start looking at time and color as well, it gets a bit complicated. I'm not gonna talk about this, but that seems to be the extra ingredient from the Gungan cells to start to mess with time and color. But then, when it really gets interesting, I think is when you start looking in the brain, because it mostly lose all these crazy opponentcies in the sense that they're not then individual cells, but they start being there in pairs of cells. So, you still see this would be a response, but it doesn't have the yellow lobes, the yellow lobes by itself. Same for these, same for these. So, you start to basically rectify them and flip them up. But what's really interesting is that in the brain, what we see is that they're not randomly distributed across the on and off space.  And I think that's leading us to what may end up being a fundamental principle of how color works, certainly in the fish and maybe across other species as well. So, I just wanna highlight from a paper here that came out fairly recently, just how dramatic this is.  And hopefully you can see that in the UV range, you almost only get on responses. If you go into the blue-green range, you almost only get off responses.  Okay, this is what that looks like and we can actually link it to the spectrum of natural light. So, the off response, which is the gray curve here, is basically nicely superimposed on a natural light curve, meaning it is the achromatic reference, whereas the on curves look absolutely nothing like it. And that brings us to a picture, I think, that looks a little bit like this. You've got your broad cells. They give you an achromatic reference. They tend to sit roughly across the entire wavelength space that the fish can see with a little bit of a UV suppression. Then you've got a lot of UV stuff sitting on the end and there's a lot of nuance. If you look at Iris poster, you see some are extremely sharp, some are not so sharp. So, there seems to be a little barcode kind of thing going on. They're all on cells. You've got a lot of on cells on the other end. They do something like this as well and then sprinkle it in between. You get the middle ones and they're also all on cells. So, basically you've got the achromatic reference and lots of on, which is narrow, which may just be how it works. And since I'm running out of time and I'm gonna zoom through this rather quickly, Shin Wei here has a poster looking at armor queen cells and he sees that the armor queen cells use the on channel, not the off channel to do spectral processing. So, when you have a bipolar cell, that's spectrally broad, you block armor queen cells, it is still spectrally broad. That's off achromatic modulation. If you've got an on cell, which is not spectrally broad, this is narrow, it goes spectrally broad. So, you've got a spectrally selective on circuit suppression. And what you've got here is, you've got an, it's achromatic under control conditions. You block the armor queen cells. The off circuit is basically still achromatic, but you're gaining here these on things which effectively gives color opponents in the end. So, basically, we've got lots of examples of this. Basically, all of the spectral modulations using armor queen cells use the on channel, the achromatic ones use the off channel. And we can actually see that at the level of the armor queen cells themselves, all of the off armor queen cells are achromatic.  So, I think there's something there. And since I'm really out of time, I just wanna zoom through three slides, I promise. Other animals. Okay, these are fish. These are not fish. They all have photoreceptors. They're all interesting. Let's look at them. So, this is a tadpole. I'm pibian, obviously. We have now started to establish the ability to record in the brain of a tadpole that's alive much like we do in a zebrafish. This is a tectomy. It's what it looks like when you zoom in. Here's just a response to a flash of light. So, it kind of works. The tadpoles, Xenopus in this case, have three, actually four photoreceptors for this age three. They've got a blue cone, they've got a red cone and they've got a green rod. Now, what happens if we look at the off response? It's basically rod shaped, making me think that this is the broad achromatic reference. If you look at the on response, you kind of need all three photoreceptors to explain it. And it's quite striking how big this and narrow this red on is. So, it seems that the tadpole is doing something like this as well. And we actually see it in the adult as well. So, I should point out that amphibians are special because they've got two kinds of rods. It's the frogs and the salamanders that do this. And Karola here has a poster on how that might be working. And basically what we see is, again, even for this rod, rod color vision, we've got a broad achromatic off channel, which is just the green rod. Whereas the on channel is more narrow because it seems to be suppressed by the blue rod, which is the second rod. So, even for the red rods, it seems to be doing this. We're looking at chicken. This is Marvin's poster as also today. There's a lot of stuff going on. And here's our dinosaur again because, of course, birds are dinosaurs. So, here's a very simple experiment, multi-electric recording from the chicken retina, 200 ganglion cells, not selected for anything except for the fact that they're responding to light. So, this is a population property. And we're just plotting here the on and the off response through these flashes of light. You can already see that the tuning function. But, if you look only at the off responses, they basically follow your long wave length option, just like the wood and the fish. Whereas, if you look at the on responses, they don't follow that. They are much more complicated and they need all of the photoreceptors to be explained. All right, maybe all except blue, who knows. So, it seems that the birds doing something like this. And I should point out, this is the tip of the ice break, what we see in relation with color and birds. The birds really are a little bit weird with color. And you should really go and look at Marvin's poster. And, even in sharks, we see something like this. And this is particularly striking, I think, to me, because they're supposed to be colorblind. And I just don't think that's true. So, sharks were always thought to be rot only animals or rot plus one cone, but that cone has the same spectral sensitivity as the rot. Therefore, it's colorblind. Well, I don't think that's true, because if we get the off response in the shark, it follows the rot. If we look at the on response, it doesn't follow the rot. It follows the rot-ish, but it sort of needs a long wavelength something in order to achieve the spectral tuning function. And we do have some immuno data that suggests that there is a cone. We don't know what the wavelength selectivity is, but I bet it's red. So, we'll see. And then maybe we have our first non-colorblind shark also using the on channel in order to do this. And with this, I hope I've convinced you that color is important. And that different concepts do underpin different behaviors and that that might be something that's going on even in mammals. And maybe we have a general principle here that the off pathway is broad, the on pathway is narrow, and that seems to just work across species. So with this, I want to thank everyone in the lab that did this, our funders, and of course, you for your attention. Thank you. Is this work? Can you hear me? So that, okay.  Thanks so much. It just was entertaining and really interesting. I just want to draw attention to one concern that I have. And this is about what we're doing as well. And that is how you decide what is something that is constant. And what is something that looks constant, but is actually conversion. Or what circuits get modified because of the particular behaviors and environments of the animals. Now, we can all agree that the photoreceptor pigments, okay, rod and cone phototransection, with a very minor variation, is the same as lamprey as it is in a mammal. You put the rod and cone responses of a lamprey on one side and a frog on the other, and no physiologist could tell the difference. Adaptation is even identical. But then once you get to the bipolar cells, even the bipolar cells, they're on and off, okay. That's very old. But deciding whether this type of bipolar cell and this animal is the same as that type in another, I think that's where things get really sticky. And the one example I would give you is again going back to lamprey, there is a rod bipolar cell lamprey, but it's off. So where does that come from? Okay, so I think we just have to be a little bit careful. And I don't want to single you out because the same problem occurs in harbor search too. It's a general problem in the field. Yeah, so thanks for this. So I completely agree with you. So what I didn't mean to imply is that everything is evolutionary related one to one. What I'm trying to argue is that there's something fundamental about animals evolving to process the information in this way. So for example, if we think about this on versus off thing that we see in the zebrafish, which I think is fairly clean. And then we look at frogs, but they do the same thing using the rods. The zebrafish don't use the rods for this. So it can't be the same circuit, right? It has to be different circuit, yet it functions in a way that's very reminiscent of. So I think what's happening there is conversion evolution that just over and over again, animals are doing this.  There's no way they're related, right? They're completely independently evolved. And yet, I don't know where Rudi are, but are these on cells with it? Well, there you go, right? So I don't know, yeah. Thanks Tom, that was super fun. So one of the quotes, I think it was from a paper of yours that just kept coming to my mind during this was the dumber of the animal, the smarter the retina. And on one hand, I wanna ask, how do the more recent studies in other species that you've been looking at make you think about that quote? But the one that really kept bringing it up was that switch between the red cone preference and the UV cone preference in the brain during the exploratory versus hunting behavior. That seems really smart to be able to pick the channel that you want depending on your biologic state. Yeah, so the two questions there. So the one about the dominance of the animal. So when we, I've got a fun answer to that. So when you look at the complexity of the retina in terms of anatomy, so we're just counting up there and seeing how big they are, you can divide vertebrates into two piles, the simple ones and the complicated ones. The complicated ones are all the ones that are not mammals or not sharks or not lump rays, right? So by that logic, the smartness of the primate should be linked to the smartness of the shark, right? So I think that argument breaks the smartness of the retina. I think that there's more factors to play. Then the, about brain state switching. Yes, I think it's about economizing resources. What we don't yet know is if it's the same neurons that switch between UV and red or if it's just different neurons coming on. I think that would be key. But it could just be economizing resources. If you've only got a small brain, you gotta maybe can't do everything at once. So we are actually in the coffee break time now. So maybe you can sort out your questions in the break. Okay.


So first I wanted to make sure that everybody remembered that fruits and vegetables are still alive after harvest. Sometimes I tend to forget this myself that this is they still respire they still lose water and sugars. And then it also greatly affects how long you can keep your your product because it could be as little as maybe a week to maybe as much as three weeks depending on where you have to go with it and how long you have to sell it. So why is strawberry so fragile? Well, they don't have a protective rind. That's the first problem. And they don't have starch as a reserve so they have to be picked pretty much right off the plant whether sugars are coming through. They don't have any backup reserves. And then on top of that because they don't have a protective rind that tend to be very tender and prone to bruising. And for that reason they're often picked into the funnel container. So the reason that the reason that strawberries are so prone to having a short shelf life is that they really really depend on the cold chain. They have to have the field heat removed because that will increase respiration, growth of decay, loss of flavor, etc. The other key thing to remember about strawberries is that consumers assume they don't have to wash them. That's of course not maybe the best assumption, but it tends to be that they'll just pick them out of a clamshell and eat them right there without ever thinking about washing. That's interesting. So, strawberry harvest. How do you go about harvesting your strawberries? Well, believe it or not, this is something if you have a you pick operation, you may have to educate people. I tell the story of the first time we brought an admin staff out to the farm to have them pick strawberries. They grabbed a total of a strawberry and ended up pulling the whole plant out of the plastic. So it's a good idea to go through the rudiments of how you pick a strawberry carefully. You know, removing it from the stem and not just yanking it away from the calyx part here, the sepals. But the important thing really to remember is that you have to have to pick them at least three quarters colored. So this would not be, would not be red enough. This would be fine. And this is getting to like the ideal eating stage but might be more prone to bruising. So usually what you're trying to aim for is summer between these two colors.  But basically for local sales in particular, you don't want to have a lot of white on there, because people are assuming that you have fully colored fruit because they're local. So it's really important that you have that full color that they look bright and glossy because that's another subconscious key to consumers that they're fresh. Certainly larger size helps children are always attracted to the large size of anything. So it helps with sales. And you don't want to have a malformed fruit. You want it to look cylindrical or these shapes are all fine. You don't want a really lumpy fruit for instance.  And that will definitely affect which variety you select. And also how you hold these fruit what kind of packaging system you use how you intend to market them and hold them at what temperature. Okay. So, usually there's a five to 18 days storage life like I said, and this here we have some very interesting idea. This is what usually happens. So this is what you would like up in the upper left corner right corner. This is the light color for it. This is a dark color. This is cultivar differences right here. And it depends to a little bit about what your consumers think some I prefer mine to be darker because I feel they're going to taste better. And people think this is too over right. So you have to know a little bit about your market and a market preference. Some people may not care they just want fresh strawberries. But the other thing to remember is what you generally start to see is mold usually gray mold or fochitis is your number one problem in storage. It will start to grow one strawberry and it'll start to grow in the next strawberry that's in contact with it. And this can happen pretty quickly especially if these guys are not kept below 40 degrees Fahrenheit. This can happen in like two to three days. The other problem you can end up with here is on the on the right again in the middle, as you're seeing bruising. And partly this is because you're losing your gloss. So this is partly a weight loss issue, and partly maybe a little bit over right. So any injury that happened in the field shows up now when you start to lose weight. And sometimes you see these these bruises hold show up simply because they're in a pack that's now getting a little too dried out. The other one that is common, but we don't always think about it as sepals. The sepals are the green part. And then they start to wilt, and then they eventually will turn brown. So, I'd like a survey this one is a great example in the middle here of what happens this is really a turn off to consumers because now it's brownish green and even if you put past the mold you still wouldn't want to eat this. So you want that nice bright contrast of green to red. Again, this all depends a lot on the variety that you're selecting the right message you know are they just the perfect pre right or perfect full color or are they a little bit past that. How warm was it the day you harvested that can make a big difference. And then that goes forward into the amount of cooling time that you have in the cold chain that you're operating with. Okay, so really the ideal is of course in the South we always hear this you know harvest when cool before noon or even at night. Trying to get your field, you're basically in the field from dawn until maybe 10am whenever you're getting to about 85 degrees you need to pull out. If you can, and definitely try and pick dry to minimize bruise and injury. It's really hard to keep a wet star break in a rain and the rain conditions look making it look good later. And also make sure if you are harvesting large sizes.  And this is a gallon size clamshell. I think here I'm sorry court size. You want to be careful not to get too big because they'll start to compact is these berries will compress on each other and start to bruise and keep the fruit in the shade and that's a little bit harder than it used to be because we're now advised not to use trees because of birds and food safety. If you have a pop up maybe sometimes that's a good idea or if you can take advantage of shade from a east west kind of location on the field and that's helpful to. And the other is to try and take your food into the coolers frequently so you can get the cooling parts started. Okay, now I like to spend a lot of time on cold rooms and I know it's hard, especially now that harvest started but it's really important if you have any kind of commercial operation that you have some type of cold storage available. And preferably something big enough your operation and it's hard to do this because cold rooms are not cheap. But it's particularly critical for small fruits you have to be able to remove that field heat, and you really with small fruits you only have two choices, either room cooling or forced air cooling. And the cooling is important because it's going to increase for days of shelf life you know if you have them here close to freezing. This would be in blackberry you're getting about 15 days of shelf life but if you hold in them a room temperature, you're getting about five days or less so it makes a big difference on your bottom line and what you plan to do those berries how quickly you plan to turn them around. So it's really important to choose what you need for cooling storage well before you're harvesting. I think most people always underestimate the amount of cold storage they're going to need. And that becomes problematic when you have a bumper crop or it comes into too much all at once. So basically the steps that are followed is to bring your fruit into the pack house place them in the cold room until you're ready to do forced air cooling if you have somebody you can spare to start doing forced air cooling you start that right away. Once forced air cooling is done you remove your fruit back to a cold room. The thing to remember is small fruits generally don't freeze. If they're just below 32 degrees Fahrenheit, they have a lot of sugars that act as an antifreeze. But generally, we see fruit are between 33 38 degrees Fahrenheit. So the problem is we run into that's often quite difficult to get this temperature to be consistent without having problems with your coils racing up. So some people will try and hit right around 41 degrees Fahrenheit a little bit less but this is a break point here because when you get to 41 degrees, but try to start to kick in a lot and it will be your your for us type to germinate. And you have to start having from this taking over. And there's a quick. This is a kind of a standard thing that's done to demonstrate the difference between forced air and room cooling. So if you starting at 20 degrees C, which is about 68 degrees Fahrenheit, it's going to take you, if you're using room cooling, it might take you six hours. If you're doing forced air cooling, it's going to take you about two hours of cooling to get there so you save a lot of time by using a forced air system, although it's another level of management. I like to talk about cold rooms really quickly because it's really important to understand that when you're looking at cold rooms make sure you have insulation on the doors and on the ceiling these are the two areas that are most ignored, especially if you're making one yourself or buying something that's already been used. Make sure that you have the refrigeration capacity for the type of heat load and make sure you have room to move your pallets in and out here they have space that you can move through your fruit easily back and forth. And also it's important if you have some sort of shade system whether it's a pole barn, or even a tree to give you a little bit of shade protection. So that's the thing we do, anytime you can buy these cheap, or they're not cheap, but these plastic curtains will help keep cut down you're not exchanging the whole room worth of air every time you go in when you use plastic curtains. They're actually pretty reasonably priced I think for, this is for a eight foot wide trailer and it was about $150 at the time now I haven't checked to see it may have gone up since then. But it's a nice little addition and it makes a big difference in your exchange of heat and cold. The types of cold rooms that are out there they're all over the place. This looks like one that was using the airline system. But usually shipping containers are probably the most popular right now because they're they're easy to get if you're near a court 20 foot container size is the most popular by far. And you can usually retrofit them pretty easily they're usually pretty good on the weeks, which is your number one problem with use containers. And then use restaurant called cold and cold rooms and freezer rooms are probably the second most popular because almost always as a restaurant that's gone out of business or needs to get their equipment or maybe wants to size up and has equipment for sale. So these can be a pretty a pretty good bargain, as long as you're careful about their status as far as them being operational. And then when this extremely popular is to do it yourself, and you can use an AC unit for cool bots. This I would not advise though, if you if you are trying to go below 36 degrees Fahrenheit. This is not for you and that of course for cold or for small fruits in general, that's going to be borderline. It's great for a relatively inexpensive fix, but if you're serious about holding your fruit for a retail market, it's probably not going to be enough for you. A little bit about cool bot has been extremely popular for about 10 years or more now. And the nice thing is, you'll pool an AC unit a regular home AC unit into running colder than 60 degrees. You have to be careful about the brands. So check this website store cold calm first started selling them exclusively here now you can pick them up on Amazon. Their prices gone up over the years it was like I think originally like $200 now they're the cool bots I think are up to three or even $400 a piece now. But they're really slick way to make it do it yourself and provide some opportunities for I always like the fact that if you have a cold room with two of these in here. One goes down.  So you don't have to depend on mechanical refrigeration repair. So that's a really nice perk, especially in rural areas where it might be hard to find that service. For room cooling you have to make sure you have air movement between your boxes and the flats and they talk about being able to walk around them. They also have to have movement between these stacks of flats. And that is to make sure that that air, the cold air continues to flow through the berries and around the room and go back through and be cooled again. Or stair cooling the tunnel system. This can be done on a very small scale. Here is a here's a commercial system where they actually have a wall unit and embedded in here. And what they're doing is pulling this tarp right here over these pallets of fruit. And there's about probably 20, 24 inches between these pallets. And you pull down your tarp, you have a weight on it. And basically you're sucking, you're making it kind of a low pressure system on the inside here. And that pulls warm or cold air from the room through here and pushes it out back up into here. And goes back into the cooling unit to be recalled. You can do the same thing yourself by using a box fan. This is kind of the idea here but instead of this fan you would just use a simple box fan from Walmart. This is really useful if you have maybe 10 masters of fruit and you stack them up five on each side you have a plastic tarp. You just turn it on. Make sure your box fan has the exhaust system pointed out into the room. And it will give you a nice quickie method of doing your own cooling. Okay, calculating refrigeration needs is something that takes a while to go through. And the best advice I can say is go to this website. And if you're not an engineer, this one is a pretty nice website because it'll let you put in numbers and calculators a worksheet so you don't have to sit there and remember all of the theories behind cooling technologies and refrigeration needs. After cooling it's really important you've done a lot to get the fruit cold. Now you really don't want it to warm up too quickly. It's important depending on what scale you have.  You can go directly from the cold room onto the truck and the fruit is just minimally exposed to room temperature. If they're starting out, it might be more like this system or this system. And you can do your own cooling in an ice chest simply by putting in frozen ice or blue ice. And that will get your temperature inside that cold, that chest. It takes a while, but you can get it pre-cold essentially if you're going to a farmer's market and keep it around, it'll get to around 50 degrees. Which will give you a little bit of cooling opportunity in a van too. You can buy these units to monitor temperature pretty cheaply. This hobo unit runs a little bit more, it's about $150, but it gives you humidity as well. And that is something I didn't touch on too much, but humidity is very important for strawberries. It's important to keep a cold room as close to 90% humidity as you can. And then these others are logger type systems. So if you're sending your load any distance at all, you want to know what's happening to it. You can pull these loggers out at the end and check your temperatures. There's some resources here. These guys will make loans and micro loans, so it's worth checking out to see what they're still offering. They've made loans in the past for energy efficient coolers. And then Stuart Cold also sells coolers that look like this. You can buy it with or with out. And then we made our own mobile cooler years ago. There's plans for that. It actually originated in Stuart Cold, a lot of people post what they've done on Stuart Cold, so it's a great resource. We just made it a little bit slicker with fancy paint job and everything like that. And then there's some other sources of information for post artist that you can go to and grading standards as well if you need those. And also, if you are not a DUI person, and you still want some sort of cooling cooler, there's a place actually that's in North Carolina that offers these pre built systems. Some of them have a cool bought system, some of them have a different type of refrigeration system. But I thought this was wonderful when we found it because people are always asking us if we made these commercially and the answer was we don't. There's now a commercial source available. And with that I will stop and take any questions.