Hey everybody, my name is Joe Sepi and I work for a company called IBM, International Business Machines. We've been around for 100 some odd years and counting and I am an open source engineer and advocate there at IBM and I'm very lucky and fortunate to have this role where I do the majority of my work in the community. I have worked in the Node.js community for a number of years and was a part of the group who helped merge the JS Foundation and the Node.js Foundation into the now open JS Foundation which happened a little over a year ago and I currently am the chairperson of the Cross Project Council which is the top technical advisory committee within the Foundation and we work in the CPC, the Cross Project Council to help projects to be successful, whatever that means for them and support them with infrastructure or security or standards or code of conduct and moderation processes, things like these. I'll also just add real quickly that we meet every Tuesday at the Cross Project Council and we have lots of work to do. If you have any interest in the work that we are doing, please join us. You can find more information on the openjsf.org site slash collaborate gives you links to Slack and the GitHub repose and the calendar and a variety of things that may be helpful. So yeah, that's a little bit about me. Let's talk about contributing to open source. I want to mention at the outset that the kind of center of the road here for this journey is talking about new contributors but I hope that I'll also raise things that will be helpful for maintainers or other seasoned open source contributors along the way as well. So to get things started, I think it makes sense to talk about etiquette and kind of how you approach open source and contributing to repositories in the open source space. I know that this can in some instances be very daunting. I understand that because every time I open up Nodecore to get some work done, I am daunted myself. So I feel your pain there but I encourage you to, you know, once you get over that wall, it's easier every other time and I encourage you to get started. I'll also add that it's when you're interacting with folks in open source, remember to be courteous. Don't be afraid to ask questions. Always assume good intentions. I would recommend that you take some time to read documentation around contributing and the processes that are in place for contributing to different repositories, whether they be, you know, code style, linting or commit message format and things like that. Make sure you put a little effort up front to understand what the project is expecting of new contributors so that you have less friction down the line. And I also encourage new contributors to, you know, be open to constructive criticism. It's sometimes difficult to put code out there and have it critiqued in an open form, have people commenting on it. But this is a great way to learn. It's really, I found the best way to learn and to engage with folks around open source because it really drives you to, you know, think through things thoroughly and to think about edge cases and testing and all these sorts of things. So remember that most of the people in open source are humans and you should assume good intentions and, you know, just dive in. And it's typically a good experience, so I encourage you to do that. Similarly, on the opposite side for maintainers and collaborators in projects, remember that it is daunting for new contributors. So be kind, be gentle. Remember, assume good intentions on both sides, right?  Let's be courteous to each other.  So, you know, on the opposite side, just make sure that things are in place for contributors to feel welcome and feel enabled and are lacking blockers to get involved, right? So one place that I would start to encourage folks to look at is the community health of a project. So if you know a particular project that you are considering getting involved in, I recommend you go to that repository and you'll notice in the tabs along the top, there is an insights tab. And if you click on that, there's a community sub tab, I guess you'd call it. And within that community view into the project, you'll find links to the code of conduct, contributing guidelines, license. You know, a few metrics that GitHub has determined are good indicators of a project's health as it relates to the community and particularly new contributors. So those are some important things to check out. Of course, you'll want to look at the license and make sure that that works for you. And if you're unsure about licenses, choose a license.org, I think it is, is a great resource for learning more about the different types of licenses and what they mean. As I've mentioned, check out contributing guidelines and such, which are referenced in the community health view there. But probably most importantly, the first place that I would go and look is the code of conduct. So make sure that there is a code of conduct in place. Make sure that you are comfortable with it to make sure that it is extensive enough that it covers, you know, the different areas that you may be concerned with. There is a contributors covenant that a lot of projects use and that's great. A lot of folks have landed on that. I know that there are a couple others, but definitely just make sure that something like that is in place. So there aren't any issues down the road. I think having a good code of conduct is a good indicator that the project takes these sorts of things seriously. And is welcoming to new contributors. And I would also, on the flip side again, encourage maintainers and collaborators to also view this page and see how your repository stacks up there. I'll mention that if you go and look at github.com slash node.js slash node and look at the community health profile. It's in pretty good shape. I mean, I think it's actually in great shape. It looks like it's saying that the code of conduct, I believe, is in the code of conduct or is it the contributing, maybe the contributing guidelines are not fully in place. But if you click through to it, you'll actually find that the node.js project through its years of work has really developed robust processes and guidelines around things like code of conduct and moderation and contributing. The documentation there is very well fleshed out. And I think that you should find that very helpful and very encouraging. These are things that we've been working on for a long time. So if the community health profile looks a little lacking, just make sure to click through and double check for yourself that the computers have got everything correctly. So moving on from, well, let me say actually, I wanted to also highlight this neat trick that I found someone posted on Twitter a few months ago, perhaps, that if you go to a repository, say, for example, node.js slash node, which is the node core repo, if you append slash contribute to any repository, it takes you to this really interesting view that it appears to collect all of the good first issue labeled issues. But it also goes a step further and I believe tries to algorithmically determine other issues that may be potentially good first issues. And I suspect that there's there are some like documentation issues in there. I don't know how it does it, but it seems like it tries to pull out issues that it thinks would be good, good first issues, even if they don't specifically have that label on them. So that's a neat trick. Definitely check that out. There's also a link there for the contributing doc directly from that from that view. So it's a really great place to get started. And again, I'll mention to maintainers and collaborators to also go to that page and see what your project looks like in that view. So moving on, we have talked about the process that a project may have in place to contribute.  So, you know, I think we've mentioned a couple of times now like get commit messages. Some larger projects are very particular about how you may format these messages code style guide documentation style guide. There are a number of things that you'll want to just make sure you're aware of at the very least, and may want to reference again before you open your first pull request that you are in line with with what is expected. And I did notice today that from the node contributing guidelines, there's this really helpful paragraph that says, and I'll read this directly, if you are new to contributing to Node.js, please try to do your best at conforming to these guidelines. But do not worry if you get something wrong. One of the existing contributors will help get things situated and the contributor landing the pull request will ensure that everything follows the project's guidelines. So these are guidelines that are in place.  Now, another thing to be mindful of are any prerequisites that may exist for a project.  There are some things you need to be aware of. And this can be tooling. This can be like underlying dependencies. But also it could be like concepts. So for example, ESLint, which is another OpenJS Foundation project, it's largely based on AST, the Abstract Syntax Tree. And so having a good understanding of how that works will be beneficial to you getting involved in a project like that. So there may be some upfront learning that you may want to do depending on the project. So now I'd like to take a moment and talk about like the typical GitHub open source contributing flow and what that looks like.  So that's kind of the TLDR really quickly, but I'll just go into each of those for a moment for folks that are new to this process. So you'll go to the repository that you're interested in. So say Node.js slash Node. And from there, you can fork that repository to your own account on GitHub. From there, you'll want to get the Git link or the HTTP link and clone it locally. You'll CD into that directory. And the first thing that I do is I check the remotes. I use Hub, which is a GitHub CLI tool. And so I just typed Git remotes. But I think like Git remote LS, I can't remember exactly, but you can see which remotes are attached to your repository. When you first clone it, it should just have the origin set to your Git repository. So the first thing you want to do is do Git remote add upstream and set that to the upstream repository. So Node.js slash Node in this instance. If you don't have Git configured correctly, you'll want to add your username and your email with gitconfig user.name and the value and gitconfig user.email and the value.  It's best practice to create a branch when you're contributing to an open source repository. And this way, if you have a couple of different pull requests that may be open, they don't step on each other. So if you keep everything in a branch, you can work on that branch and know that the next pull request you open isn't going to include these other changes and muddy the waters. So always use branches. You'll basically do your work, the changes that you want to make. And then you'll get add the files that you're going to include in this commit. And I'll say really quickly that it's best to keep your changes to a small set that is focused on a particular issue. Try to avoid larger pull requests that may touch on a variety of things. You want to definitely keep it as tightly knit as possible, as small and focused as possible. So once you make your changes, you'll add those files, git commit, I'm sorry, git add, and then your files or git add period is what I usually use when I'm just focused on one little thing in a branch. Git commit, I typically add my commit message in line, whatever works for you. And then you'll git push origin, your branch, right? So that's kind of the typical flow.  With a project that has a lot of moving parts, a lot of things changing. You may also want to git rebase your changes from upstream so that when you create your pull request, it's in sync with what is the latest. And you may need to do that on an ongoing basis while your pull request is open. But you can do that with git fetch all, git rebase upstream master, and then git push force or force with lease. A note that while rebase is my friend, I think it should be your friend too, but you need to be aware that when you push something with force, it rewrites history. So it can be dangerous, but just use it wisely. I use it all the time. So that's kind of the typical flow. Within that tool that I mentioned earlier, Hub, you can create a pull request directly from the command line. And it's a good workflow to be using when you're contributing to open source. But I wanted to highlight that's not all contributions are code. There are a number of ways to contribute to open source projects. And I think that this is important to call out. So just in general, documentation is always a good place to get involved. In fact, a few months ago, I was working on a Gatsby site, and I found some discrepancies, some things that weren't particularly clear to me. And I just went and cloned the repo and brought it down and created a pull request. And the gentleman that leads that project, his name is Escaping Now, was really very courteous, very appreciative, and I was happy to contribute a really good experience there. So that docs are great. If you have interest in building websites, you know, a website for the project may be in place, and you can help there. Project management, frankly, is something that is always needed in an open source repository. And then there could be other things like social media, community outreach, those sorts of things. And I'll touch on that more in a moment. I'll just also add to that with projects like Node-RED, which is another open JS foundation project, you can contribute nodes to the programming interface. Loopback is another open source project that I've contributed data source connectors to and done work outside of core that's helpful. So there are a number of ways that you can contribute that aren't just the core code or even code at all. So another few ways that you can do that within Node is that we have these concepts of initiatives and teams and working groups. So some examples are the release team, which involves code for sure, because you may be back porting some things to different release lines. But that's always a very active team that you can get involved with. The build working group is another team within Node. There is a website redesign team that's been active for a while, and that's a great place to get involved too for Node. You're writing more kind of front end code for the website. Internationalization is another great place. There are not only the translations that are needed, but also the underlying work that supports the translation effort, the internationalization efforts. So those are a couple of good places. And then I mentioned social community outreach. Node has a newly formed social team. So there'll be a group of us that are actually managing the social media presence. There's, you know, in the past have been community and outreach programs as well, that are great ways to get involved. And then there's a new initiative recently started for examples. So good, straightforward, simple examples for a lot of common use cases. So that's another place that we'd love some more contributions. And speaking of all these things, I want to mention that the collaborator summit was on Monday and is happening again on Thursday and Friday. So that's another great place to get involved in open source and the work that we're doing and the foundation and such. So a lot of people will ask me, you know, how does one get their company to get more involved in open source? And as I mentioned at the beginning, you know, IBM is very supportive of my work in open source. And we have a lot of folks in IBM that are working almost exclusively on open source. But I've worked in a variety of other companies where, you know, it was a little bit more of a struggle to get company time to be involved in open source. And there's an initiative called open source Fridays that I think is maybe started by GitHub. It's a good website that kind of is helpful in trying to do more of this stuff and particularly like dedicating Fridays to it. What I found successful at my time at Behance in Adobe was that we were doing a lot of work in open source. We relied on a lot of open source tooling. And so we took the Friday approach, but we we alternated between one Friday would be like we would call it a bug bash. And we would just try to clear out, you know, bugs in our in our backlog. We wouldn't focus on sprint work and feature work. We would just try to knock out bugs. And then the other Friday we would alternate would be an open source Friday. So, you know, one Friday's bug bash, next Friday's open source, bug bash open source. And so that was a really great, like kind of middle ground compromise that I think could work for a variety of development teams. So you may want to consider that. I'll also point out a couple more resources for getting started in open source. There's the great for new contributors showcase that that GitHub has. There's the open source guide, which is great. It has a whole how to contribute section. There's also a first timers only website. That's a good resource as well. And then I'll do a little shameless plug as well. I've started an open office hours bi-weekly meeting for the open JS foundation and we meet every other week. And sometimes it's just the open office hours on a few occasions we brought in project maintainers, someone from Express, ESLint, internationalization and Node.js. We have a few more that we're lining up after the event. And that's I think a really good place for folks to come and ask questions and to learn about how to get involved in particular projects. So if you go to github.com slash open JS dash foundation slash open dash office dash hours, you can see more there. And that's my talk. I hope that you all get involved in open source. And I hope that it's a really great experience for you. And my Twitter DMs are open. So feel free to message me or if you join the open JS Slack, feel free to message me there. I try to spend some time helping new contributors get involved. So just reach out and I'd be happy to help you too. Cheers.


My name is Dee Scoper. About half a year ago, I proposed for Fujitsu to work with the community to build an app auto scaling project. There were some rumors from IBM that they would open source theirs, so I thought it would make sense to work with them. That all took a while, so in the meantime, I've taken over the PM job for the CLI, and in January I proposed it to the community again, and got support from SAP and IBM joined us then. And now, as you know, about a month ago, we went live two months ago, and Michael Franco, who will lead this presentation, has taken the job of the PM. And Bo Yang has been on this project at BlueMixell. He's most familiar with the actual solution that we're starting out with. Would you please? Sure. So what we're going to do is the slides will show you where we are or were, and then explain what it is we're providing as part of our MVP release. And then more importantly is what I'd like to do is really get an active Q&A to understand what people are really looking forward to see once we have the foundation in place, right? So right now, as Dee's mentioned, we're incubating out of the Cloud Foundry incubator. If you go there, there's actually a repository that has working code. However, it's based on CouchDB, so that's one of the reasons why we recently, as of last week, re-incepted to move over onto a data store that we would prefer, which right now is Postgres. So we are moving from a NoSQL to a SQL model. And at the same time, we've decided to re-architect exactly how the foundation of autoscaling will actually work, so that way we can actually move forward with the requirements that, at least across the initial three companies that are participating in this project, see in the near term. So as mentioned, I'm the project manager for this, and I'm lucky enough to have teams everywhere but the United States. So for me, being in the East Coast, I have teams that are 12, 14, and 9.5 hours off where I am. So I either come to the West Coast, or I go somewhere else so I can talk to them, or I just make it work. So the common question is, what is autoscaling? Well, in today's world, it's, I can scale up and I can scale down. It's pretty easy. All you need is a human to just hit the button every time you want it to happen. So obviously the whole point behind the project is to automate this. And the real question is, what is this? And from here, I will let Bo describe exactly what it is we're providing and how that really works. I would take some time to give you the basic idea of autoscaling service, how it works, and also introduce what are the interfaces we provide today and maybe in the future so that you can interact with the autoscaling service. So there are multiple ways we can automate the scaling of your Cloud Foundry apps. So one way I guess most people can think of is, you know, we may want to scale the application based on the metrics. The metrics may include some of the, you know, metrics that your application is using in the system resources like CPU memory or some of the metrics that, which is specific to your app. Like in the Java, we have a JVM heap. And maybe sometimes you want to scale your application based on some of the internal data structure that your application is using. You have a queue in your application. You really know that basically if the queue length is too long, you want to scale up.  So with this actually, the autoscaling service provides a way for you to scale dynamically based on these kind of metrics. So, oh, sorry. Okay. Let's go to the next one. I will, you know, go back to this, what are the interfaces we want to provide, right, to interact with the autoscaling service, right? So with dynamic scaling, basically it is, I would say it's a feedback controller, right? It's pretty much common in the mechanic engineering and also pretty much common in the computer system. So the feedback controller is basically something, you know, a control system or management system that you basically regularly check your target system and make a decision how to do some changes and apply those changes to your target system. It's not a one-off action.  It's a sense and a response in a regular way, right? So the metric-based scaling is such a way. Basically, the autoscaling service will collect the metrics from Cloud Foundry and decide when we want to add the instance or we want to remove the instance and how. How this means that how much, how many instances I want to add, how many instances I want to remove, right? So here I give one of the examples, which is basically memory. We want to do the memory-based scaling. So the graph above, please show that, okay, at some time at a non-Cloud, there are more traffic coming in. I may need more, you know, memory for my application. And then after some time, like after 11 o'clock p.m., then the traffic goes away and I need less, right? So how we are going to do that with the autoscaling service? Basically, the service itself will, you know, collect the memory usage from the CF system. And then they said, okay, there is not enough memory because there we define some rules. This means that, oh, okay, if the average memory usage is greater than something like 17%, because your application needs more. So the current instance, if you compute the average memory consumption, it's increasing. Then it's greater than 17%. You want to take some action for SQL out. So you specify, oh, I want to add two more instances, right? Then the system will take that action. Well, because your memory demand continues to increase, so this kind of change will not satisfy your need.  It's still, you know, the memory usage is greater than 17%.  So that is basically the idea of the, you know, memory-based, you know, autoscaling in this case. So there is a similar thing when you scale down, scale in your application, right? You don't need so much memory. So you remove the instance automatically based on some of the rules. The advantage is obvious, right? You don't need to take care of what kind of workload of your application, right? The autoscaling service itself will just sense and respond. Well, there are some drawbacks, obviously, right? Because there is a control loop, so basically you need time.  It will cause kind of a fluctuation. So your control, maybe you intentionally slow down that action, right? So this, as a consequence, sometimes it's a little bit behind the resource demand of your application. In order to solve this issue, actually, not fully, but one of the ways to do that is that we provide another way for scaling. It's called scheduled scaling. So if you really know the workload of your application, you know, given time period, you need more instance or you need more resources that you can do based on the, you know, scheduled scaling based on time. So in this instance, basically means that, okay, just before, you know, 7 o'clock, 15 minutes before 7 o'clock, giving me at least 180 instance so that I can get prepared, right? And also the 15 minutes maybe give me my time to warm up my instance so that we are ready to serve your workloads. So this is the best idea. If you look at this, actually, the schedule scaling doesn't define the metrics but define only the time period and also the minimal instance number and the maximum instance number. It's not going to define the zero one because you may want to kind of select flexibility for the number of instances even during this time period. So during this time period, if you already define the dynamic scaling policy like the memory based is still applied but within the new minimal instance number and maximum instance number. So that is how the schedule scaling works. And a little bit about maybe I could go best because we build as a service. So basically we follow the CF service broker API. So once you want to use that, it's pretty simple, like you use other services. You create a service and bind the service to your application, right? It's done. And when you bind your service to your application, one choice is that you just specify the policy or the rules in the commands, in the parameter when you do the bind services. There are some other ways to define the policy. There is an API exposing the ways you can create policy, you can attach policy, you can detach policy and delete policy, right? I will not show the JSON format of that policy but this will show some kind of UI. Actually for the open source one, we don't have this UI but we show this, trying to give you a big idea what are defined in the policy, right? Basically there is minimal instance account, maximum instance account for your application. It's a similar case for when you define other scaling group in Amazon, right? Web services. And then there will be for the metrics one, you can define several rules, you select the metrics type. In this case, because now today we start with memory, you select memory and you select the scaling of the rules and also specify the scaling rules. Like in this case, if the memory utilization is greater than 80%, I want to increase one instance. Well, if it is less than 30%, I want to decrease, right? And you can increase with a specific number of instance. You can also increase or decrease with a percentage, right? I want to increase 10% or 30%. I want to decrease, you know, 10% or 3%. There are also others to control, detail the parameters, control the whole outskilling activity. Well, I don't want to describe that. Maybe, you know, if we will go to the open source project, there will be detailed documents seeing how you control others like, you know, what will be the statistics period and how you are doing the statistics and how to, you know, kind of conflict what will be the cooldown period for when you do the scaling, you know. And also, schedule the policy. We provide two kind of schedules. One is, you know, repeating policy, right? Basically means you specify start time and time. And also, you repeat on specific days, right? In this case, you can repeat on Wednesday, Tuesday, some days of the week. Maybe in the future, we can consider, you know, some days of the month or some day of the year as well. And besides that, you can specify a specific date. You give the exact, you know, the day, exact the start time and time. And, you know, the minimum and maximum instance number. So besides that, besides you cross RUD the policy, you may want to, you know, say how it does, how the other scaling, you know, does with my app. So we also provide kind of APIs so that you can retrieve your scaling policies. This means that whether the scaling is successful or not, when it is started to scale, and what is the reason why we do the scaling, right? A number of information is here. Okay, this is pretty much I want to share about, you know, how it works and how you can end up with other systems. Right, so for MVP, we're focused strictly on memory and it's easy to explain and understand, but it provides the most simple way for us to deliver something where, again, it's the framework that's most important right now. So where we're looking to next is, you know, other things that we can scale based on which will come after. We're looking at collecting response time metrics from the router. So that way you can do it either based on throughput or total response times and decide if you need to scale in or scale out based on requests taking longer or shorter, right? Which is similar to how memory works, although for a lot of, well, so if you use Java as a bad example, where memory pretty much looks flat from the outside, you don't have a lot of real insight to it but your response time will be more relevant. Other things we're looking at is providing a way for application developers to actually provide custom metrics because in the Java case, you could record the actual heap usage, which is a more representative usage pattern of what's really happening. So, you know, you can see that, yes, you're only using 30% of the overall memory usage that appears from the outside, so you get better granularity. Obviously, in order to do that, it's something... We're discussing different ideas as to what we expose to the application. Obviously, it would be a way for the apps to push this quote-unquote metric. I mean, to us, it would just be numbers that we just, you know, using the basic rules is, yes, you exceeded some value, we don't know what it is, we don't care, and magic happens. The devil's in the details on who does the aggregation and if you want averaging and other capabilities. So that's part of the reason why, by starting with at least one thing, we get a basic understanding of how much we will do as part of the autoscaling service versus how much has to be built out when somebody may want to introduce a custom metric where part of it may be a two-part thing that aggregation is an onus on the application developer since we don't really... We may not understand instances and other nuances. So again, there'll be some experimentation when we get into custom metrics. And much like response time, there's the opposite, which is throughput. And as Bo gave examples, there are things that are obviously external, which is the router that we can get metrics from, but there may be more throughput optimizations that are internal, like if you're using a queuing system or you're using some back-end service, and it may be related to the throughput to those services that you want us to either scale in or scale out. The last thing I put up was CPU, I gave it a funky-looking question mark. And the interesting thing to that is right now, I'm proposing that we don't even go near CPU because it's a thing that makes no sense. It makes actually little sense given the platform that we're given and the actual metric that we're given because we actually are only given one number of percent CPU, and we really don't know what that number means because it can fluctuate from as low as, you know, if you're on, let's say, an 8-core box, we may get a number that says you're using 1% CPU and I can get a number that says you're using 800% CPU. And I don't know, and I don't think anyone can relate as to is that good or bad, right? Is do I scale out or in when I have 800% CPU usage? Right, because it could be you're just using the box because we have extra capacity and you can burn that much. So, you know, trying to scale in because it appears high is not the correct action. It would have made sense if we had known more about the CPU usage of the host, how much is actually left over, what you're using and if you had a cap. But we don't have that information and we can't easily get that. So, right now, CPU is off the table. So, that is it for our presentation, but I'm more interested in what people are, people being users of the system are more interested in when we talk about auto-scaling and what they're looking for in a type of system like this. Anyone? Anyone? Questions? Right, and again, right, people have to realize that these types of automated systems really don't react. The purpose isn't to react fast, because like in your example where you see the number of requests go from 1 to 10 instantaneously. Right, as long as it's a sustained number of requests. Right, and that's really what the system is trying to do is trying to smooth it all out. But yes, given the approach we're taking, you can have any number of rules. One of the issues that will be interesting is when an application has multiple rules, you can conflict. And so there has to be a prioritization that obviously scaling in takes precedence over scaling out if you have multiple actions that need to take effect. And the moment any action is actually taken, Beau mentioned it but people may not have caught it, is that you do enter what we call a cool-down period where no action can be taken, because we need to actually let the system catch up that even though we say scale up or scale out, it takes some amount of time before, one, that action happens, and then two, that it gets reflected in the metrics. So there are interesting effects that can occur where people want things to happen faster than what they will do. Now, it doesn't stop anyone from doing what I showed on the first slide, which is scale the app in and out yourself. However, you do have to be careful because you do tell us the minimums and maximums that are expected, and so if you happen to go outside those boundaries, we may actually rescale you back into the boundaries that we actually know about. And that does depend on what triggers us to actually detect some of this, because again, we're focused on the rules, not so much the schedules are only evaluated at the time that they are triggered on the edges, not in between. So the service broker is just there as a way to inject the policy into the system, right? And from that point on, as long as the application is running, the rules are in place, and you can change. So we're starting with you provide us the policy per app. We are looking at, and we've designed a way to do it where you can have pre-built policies that are named, and so when you bind the app, you can just say refer to that policy if that's what you want. It makes certain things a little bit harder because you have to first go to the service, define the plan, or define it on the service instance, and then when you bind, you then do the attachment. Okay, so you talked about scaling based on resource usage and performance metrics, but what about price? For instance, if you run AWS, you don't want to pay 4,000 resources just because there's some contention. So the question is, can we scale based on price? So the way I would turn it around and say that's what I would view as a custom metric, and you have to somehow relate the pricing to us because we're not going to know that. We have no idea how you're being charged, why you're being charged. The onus will be on whoever implements the custom metric to relate some piece of data that takes into account pricing so we can do the right thing. So I mean the end user would want to specify the price to the capacity in some sense. And then you know the cost, so you could compute that, right? Right, so for us, again, it's all black box. So we would see things as numbers. The fact that it represents a price, okay, fine. But we would need, the trick is we need the metric that we can just hook up and just compare the numbers because that's all pricing really is. A high price, a low price with thresholds. You don't really, you know, it could be marbles for all we care about, right? At some point it doesn't matter. Thank you. No, but I can control the instances that could be dry. So it depends on how price factors in. So if price is really based on number of requests that I'm interacting with the service, and that's really driven by the number of instances of an app, right, hypothetical, right? If I scale down the number of apps, I'm also potentially scaling down my cost potential. Right. I have a quick question about the, when you push an application that's already been auto-scaled higher and you're specifying resource limits in, say, the manifest, will that then cause the application to be scaled back down to those initial limits and then the auto-scaler has to kick in again? Yes, so the question is if your manifest specifies a number that is outside the bounds of the min or max, what will the auto-scaler do? And yes, the auto-scaler could care less what your manifest says because it's just looking at what you specified in the policy and what the actuals are or your desired at the time. And your manifest is really reflecting the desired, but the policy will always try to override that, which is why I was saying there are cases where you can fight the system, but the system is going to keep reacting and potentially undo whatever it is you're trying to do. Correct. Count me as one who was perhaps snively hoping that you could scale based upon CPU. I was wondering if you could talk a little bit more about that problem. I understand the number of cores problem. If we could provide a factor perhaps to the auto-scale service, perhaps we know all of our execution agents have eight cores on the box. Are there problems beyond that you could help me to understand? So, one, I already know that that's not true, that people do have different numbers per cell or endpoint agent because I made that supposition as well, and then I was corrected that it does vary, plus the fact that operators are allowed to put in over-commit factors so we can lie about all this. And the problem is that the metrics we get back are not a reflection of the lie, but are actual reality. So we have two... Well, we could get... One is we would have to get more information, and then we would have to get enough information that the lies don't matter, right? So, over-commit becomes a real issue where when you start lying about your capacity, you're purposely trying to drive your CPUs lower, or the usage per application lower in a highly high density type environment. But when you have low density, right, you have freedom to consume all the capacity, in which case the numbers don't actually are flipped and the way you're specifying thresholds don't make sense. Right, so a concrete example is normally in a traditional workload, you worry about, oh, look, when this box goes to 90%, I'll get an alert and say, you know, I need to spin up more instances. Okay, but on a box that isn't used and you go to 90%, well, hey, that's great because your one instance is handling all the workload that you need and the fact that it's a 90%, well, why do you really care? I mean, perhaps it could be an indicator that more could become, and I mean, if I chose a threshold that, you know, if my app goes over 80%, maybe I won't. Right, so what we can't do is we can't tell if that is really, and you may not have a good, you know, so you could argue that, yes, once I go to 90%, you know, spin up more instances, you know, and we could do that. The question is, is that correct for most people? Not sure, but I mean, we could add that type of supports for CPU. It's just unclear that, you know, the fact that it's not so much 90%, it's the fact that, oh yeah, I can hit 800%, and so when you set the threshold at 90%, and all that means is, well, you have less than a core, right, and the fact that, yeah, there's room for eight of the, right, you can use all eight, but I won't let you because I'll keep spinning up more instances instead. That's when, you know, you're getting, you're paying for more when you should be paying for less. Right, so that's the struggle, is if I had known, oh, there are eight cores, and oh, by the way, nobody else is using this excess capacity, you've basically used all of it because you can. That's when we have to think about, okay, scaling out isn't potentially right at 90%, it's more correct when I'm hitting the threshold of the box. So it's like 90% of the available capacity versus 90% of what I would think of what my app is using. Which might be impacted if I have other applications on the box using 50% as well. Yes, and that's why you need, you know, more information about the box and the overall usage of the box independent of your app. Okay, thank you. So you've talked about horizontal scaling here. Do you plan to support vertical scaling where you will increase the size of the container when the memory goes up? No, that's your problem.  And part of the problem, again, is like for Java. So some of the languages are more geared toward that type of workload, but if you're doing Java, right, the heap is tuned to the container size. So unless we can get heap metrics, we can't say, hey, let's grow your memory. And to do that, now we're getting into potential outages because the moment I say, hey, I want to repush or scale out and increase memory, right, things have to be not so much restaged, but restarted everywhere with larger containers. But we do have zero downtime deployment available in CloudFormby, so that could be leveraged. Yeah, except it doesn't happen in all cases. So you have to be careful that you could have, I mean, you can mistakenly cause things to happen if I try to do certain things. I mean, for that type of scenario, part of it is how much should we do as part of auto scaling versus how much should you be doing through your own monitoring of your application to make sure that things are sized properly. Okay, thank you. With respect to both the auto scale options, which one has precedents? Between what and what? Between scheduled and... Right, so the question is between rules, triggers, and schedule, what has precedents? So they actually do two different things. Schedules are all about setting or resetting the min and the max boundaries, and the rules actually are the triggers to cause an action to be taken. So they actually work somewhat in conjunction, where the one is what we call is dynamic, right? So the triggers or the rules are the dynamic things that are constantly being reevaluated, and schedules just occur on some interval, right? So when an interval occurs, the min and the max potentials adjust, and that could cause something to go up and down, but the triggers or rules are the things that get evaluated to determine, do I increase or decrease over that schedule? Right, so they actually work together. So they're complementary instead of opposing each other. Okay, sure. Any other questions? Okay, well, thank you for coming and listening to us talk.


So in particular with COVID and the SARS-CoV-2 protein available now, there are a ton of groups working on this including us and colleagues. So these are examples from molecular simulations of the spike protein seen from the side and from the top. Again, this is a small protein that creates the small patterns that are crown-like. The part up here is the receptor binding domain, and you see three of them at the top here, and we already know that one's going to bind to the ACE2 receptor on humans. The only question then is that first, how will this stick together? Exactly what will that ACE2 receptor look like, and can I bind a small drug maybe to either the virus or the ACE2 receptor and prevent this from happening? That's a bit of hand waving, so we need to be slightly more concrete. What I would like to find is a way that I can rapidly find the best ways to put two molecules together. And here I'm primarily thinking of the small molecule, the drug I'm going to design. I might think of both the spike protein and the ACE2 receptor as one big complex. This process is called docking. And there are two keywords here. First, I'm going to need to find the best way, and I need to find it. Find means that I'm going to need to search. I will need to test lots of different confirmations. Best means that I'm going to need to score it, so I can write that. There has to be some scoring here. In theory, you could calculate the free energy in a simulation, but as I already hinted, that's going to be too expensive in practice. Second, we need to identify ways to put at least two molecules together here. That means that I will literally have to search by trying to fit the molecule in lots of geometrically different confirmations. And in a way, you almost did that already. Do you remember lab one when you used a Monte Carlo algorithm? You didn't have a continuous energy landscape, but if you test that position or that position or that one or that one or that one. Here, if we just want something that is super fast and that we accept that we might be a bit sloppy, Monte Carlo algorithms might actually work quite well. I'm going to need to find a way to rotate the molecules. I need to decide how much freedom I will allow in the molecule, and this is a complicated balance because the more accurate I do things here. Accuracy sounds good, but the more accurate we do things, the more costly it's going to be. Here, the whole assumption here is that this should be a fast and relatively sloppy method to ensure that it's 1000 times faster than the experiments. So I will not go for accurate here. This requires us to develop two things. First, I need some sort of sampling. For instance, Monte Carlo sampling. I need to generate many different conformations, ways of putting these molecules together or putting the small molecule in the receptor. For instance, rotating it and changing all the bonds in the small molecule. Second, we need some sort of scoring method or ranking method. Given all these different conformations, I need to be able to say which ones are good, which ones are bad. Keep the good ones, try to find even more good ones while we ignore the bad ones. Nothing here requires me to sample properly according to the Boltzmann distribution or anything. I couldn't care less about proper physics. I just want to make sure that I find some good hits in this case. So if sloppy is the middle name, let's be sloppy and see how we can do that.


Hey there lads and ladies, it is Petrifying Pumpkins here back with another Firewall Zero Hour video. This one is all about the huge and extremely moist new update coming called Operation Nightfall. And yesterday we learned loads of new information regarding this, including its release days, which is the 21st of May and that is of course next Tuesday so not far away at all, get absolutely hype and we have pretty much all our questions answered from the last video that I did so without further ado let's just jump right into it and get into these juicy details. Okay so yesterday two things happened, we got a brand new trailer that details a lot of the changes coming with Operation Nightfall and I'll have that playing in the background right now but we also got a blog post from Damon Shabs over on the PS blog where he goes into the nitty-gritty details of what we can expect and there is a lot of information here. Now the first thing Shabs talks about is the brand new seasonal progression system that has been added to the game and this revolves around missions, tasks and rewards. So it kind of resembles a battle pass if you've seen that in Fortnite and the kind of battle royale games. So Shabs talks about how they've changed up the current challenges that are in the game and made them more meaningful. So that means either challenges have been replaced and are no longer in the game or they've evolved into one of these missions or task category type things. So what is the difference between a mission and a task? Well each week we will be given a mission which will yield some kind of cosmetic reward upon completion. Tasks on the other hand are daily and will reward you with just crypto and XP. Now things do get a little bit complicated here because there are more than one type of weekly mission. So this is because first contact entertainment are adding an up pass to the game. So for the price of $9.99 you can purchase this pass and get access to some extra missions in the form of premium and bonus missions which will unlock more cosmetic items. So let's take a look at this image here from the PS blog to see what the difference is between having the pass and not having the pass. So whether you have the pass or not you will get access to the two new maps which are Hanger and FOB. Though FOB won't come out until halfway into this season. Daily tasks and 8 free mission rewards are the other two things that everybody will be getting. Now the rest of the list then here is just for those who will be buying this up pass and those benefits include Ace Premium Mission Rewards and Ace Bonus Mission Rewards. And I'll be very interested in finding out what the actual difference is between a premium mission and a bonus mission. You'll get access to two new contractors Ruby who we have already discussed and a new contractor called Lynx who we know very little about. He'll be added halfway through the season and is briefly teased at the end of this trailer. You'll also get access to two new skills one of which is Ruby's Thief skill. The other one will be Lynx's skill but we don't know that one. Yes, but we'll talk about that a little bit more in just a bit. Now the skill thing here feels a little bit like walking on thin ice. On the one hand Shab's later points out that the skills are just timed exclusive to up pass holders and that after the nightfall season ends the skills will be available to everyone. But on the other hand this opens the door for a pay to win debase. Now Ruby's skill, Thief isn't exactly going to win a game for anyone but if Lynx's skill is more impactful and I think it will be to the gameplay then it could be a little bit problematic. Let me know what you think about this in the comments below. Finally up pass holders will have a chance to unlock a legendary weapon skill. For Operation Nightfall this will be Okoro's AK-47 and you have to admit that thing looks bad as the lion caravan on the stock is truly moisture inducing.  So that's the 8 free missions, the 8 premium missions and 8 bonus missions. And you'll need to hand over on top of all this 250,000 crypto which is a considerable amount. I think I only have something like 200,000 right now. So maybe I will be using that Thief skill after all. Now you may be wondering where the new weapons are on this list and I believe they are going to be free mission rewards but we'll get to the weapons in just a bit. Next up Shab's talks about the new contractors and new maps. We'll be getting two of each. The first map, Hangar, actually takes place in Malaysia. Now is this some kind of nod to Malaysian airliners going missing or something? I don't know. But in the developer stream the UI states it that Hangar took place in the UK and that's something I went over before so it turns out that must have just been a placeholder. Now the second map which will release sometime mid-season is called FOB which stands for Forward Operating Base and we see it teased here at the very end. Now the most exciting part of this map is that we see it has weather effects. Now in this case a sandstorm. So we can assume this takes place in a desert environment on some type of military outpost. I'm getting very big Metal Gear Solid V vibe from the shot we see here. Now during this tease we also get a glimpse of what I assume is the new contractor, Lynx. Now we see Lynx in the distance but he is clearly in a downed states. Then we hear the revive audio cue. Take a listen. And Lynx rises to his feet. This feels like a big clue to Lynx's skill being the ability to revive himself from a downed states. It is possible that an off-screen teammate shot him with the revive dirt but I think there's just too much emphasis on the revive aspect for it to be anything else. If true then this resurrection skill we'll call it for now would definitely impact gameplay more than Ruby's thief skill and then you're talking about pay to win kind of stuff. At least timed exclusive pain to win if you know what I mean. So that can get a bit messy you'll be interested to see how the community reacts to that. Next Shabs tells us about the three new weapons coming with Operation Nightfall. Two primaries and finally a secondary for the first time. So we're getting the Richardson SG-12 which is a cool looking pump action shotgun that seems to be based off the Kel-Tec KSG if my googling skills are accurate. Next we have the Sarge which is a pistol based on the iconic 1911 and is the very first DLC hang on added to this game. Hopefully it'll be good enough to make me think about dropping the very useful revive pistol in order to use this instead. Now finally we have the Raptor which we already talked about in the last Nightfall video so I won't repeat myself there. Now interestingly in this image we see that each of these weapons is a mission reward so the shotgun is a week two reward the pistol is a week five reward and then the raptor is week seven. So this raises a couple of questions. Firstly when we are rewarded these weapons do we immediately receive them or do we still pay crypto to access them? And also what happens if I don't do the week two mission for example? Do I miss my chance to get the shotgun? If so do I have to wait until the season ends before I can get us? Like with the skills? I don't know. Let me know what you guys think down below in the comments and how this is all going to work. So Shabs then goes on to talk about the new UI and quality of life changes. Now we've covered a lot of the UI in the last video but there are a couple of differences here this time and some things that we now understand better that we didn't know the first time. So starting with the operations tab this has been renamed to the missions tab and I'm guessing this is where you'll go to see the current weekly mission. On the left this progress bar had us baffled last week but we now know it's a progress bar towards completing all 24 of your missions. And finally the mysterious USB symbol has been revealed to be a hack key and we'll talk a little bit about hack keys in a minute. First Shabs talks about the quality of life improvements we can expect to find in nightfall and these include squad optimizations, the ability to customize contractors in your lobby, hallelujah can we get an amen, map and laptop location refresh in bunker and compound which we already knew, as well as updates to enemy indicators and headshots sound effects. So keep an eye out for all of that stuff. Now next up Shabs talks about enemy AI which I found very surprising. First contact entertainment have been working on improving enemy AI and we even see some of this in the trailer. AI will now behave more like real players, breach indoors, hunting you down and using equipment intuitively. So you can expect an even bigger challenge from the level 50 AIs in this game than we already have now. Lastly Shabs talks about new ways to access more content as well as changes being made on the ps store to existing content. So Shabs breaks it down here, Operation Nightfall itself is free for everyone and will install as a free updates to your copy of the game. The nightfall up pass then will give you full access to all of the nightfall missions and rewards that you can unlock. But for those who don't have time to be completing all these weekly missions and whatnot you can buy these hack keys. So hack keys can be used to instantly complete a weekly mission but only free missions. Doing this won't give you XP but you'll receive whatever the cosmetic reward was for doing that mission and hack keys can be bought in bundles of 5 for 4.99. And then finally there is the nightfall up pass plus 25 hack key bundle. Now the price isn't listed for this bundle here but if you do buy this you can use these keys on any type of mission free premium bonus whatever unlike the five bundle keys. So keep that in mind when you're buying if you're deciding on buying five key bundles or whatever that the five key bundles will not work on premium or bonus missions. And then at the end of the ps blog article here Shabs talks about the current cosmetics that we already have on the ps store. They're all going to be reformatted into seven different bundles and will be available for one week only. After that time they'll be removed from the store. It says here that after May 21st cosmetic items will be available in-game as rewards for completed missions. Now I don't really know if that includes the ones they already had on the store or if those ones will be gone forever. So I'd like to see a bit of clarification on that one. Now in the comment section of the blog Shabs answers an important question that came in from Kusman who you may know. He just watched this channel from time to time. How long will a season last to which he replies 12 weeks. Stating that if you want the legendary Okoro AK-47 then that's the amount of time you have to earn us 12 weeks. And then that's it from the blog from Shabs. Now let's take a closer look at the trailer to see if we can spot anything interesting and almost straight away we are given an example of what a task will look like as on this monitor we can read the following. It says task one eliminates certain number of players with any smg and beside us are spaces for how much crypto and xp that task will be worth. We also see a progress bar beneath it that shows he's got 25% of the current task complete. Now this could just be a stylized graphic so it might not look 100% the same in the game but I think that's probably a realistic example of the types of tasks you can expect to see in this game. Next on this monitor here we see the map layouts likely for the hangar map itself so you can get an idea of how it will look and the size of us. We get a good look at the unique reload animation here for the new shotgun before we see the new AI in action busting down a door. Here we also get to see the 1911 in action with the suppressor attached. We see a screen here teasing a weekly mission but it doesn't reveal any details as it cuts away before the file is finished loading. We get a look at new face paints and camouflages and new trinkets which include a pair of grenades and a gemp head. Now keep in mind this is the stuff that you will be unlocking by doing these weekly missions it's all cosmetic stuff. Next we see Ruby's thief skill in action which nets her 115 crypto from this poor Odin player. It's hard to say for sure if this will be a set amount or if better performing players will net you extra cash but for now it's probably safe to assume it's 115 per body. Here we see Ruby holding Okoro's sexy AK-47 and then the trailer ends with the teas that we've already talked about so I want to talk about it again and whoof that was a lot to go over. This really is Firewall's biggest updates ever and it might really change the flow of the game. It certainly raises a lot of questions. I would imagine that there will be another season or another operation when this one is over that will bring even more content, more legendary weapon skins stuff like that because remember a few months ago Hesperber stated in a reddit thread that they were working on six new maps and that two of them would arrive in the coming weeks or months. Now the first two are Hanger and FOB so if the remaining four maps follow this password then first contact entertainment probably have at least two more operations lined up with two new maps for each one. And let's remember one thing it is not often a PSVR exclusive game gets this kind of post-launch support so first contact entertainment I think are to be applauded for not forgetting about this game. Yes the game does have issues, yes there are bugs that need fixing and improvements that would be very welcome but we know about them, first contact entertainment know about them and who knows maybe a lot of those fixes will be included in this update but they just didn't mention them because they aren't really selling points. For those of you who are currently loving Firewall however this update looks very promising and I think it might be worth picking up an op-pass for 9.99 if you feel like you want to support this small team of developers who are breaking new ground on PSVR. Anywho that's it for this video lads and ladies before I go let me give a shout out to my supporters over on patreon who are currently helping me get a better quality microphone for making these vids and I have to give them huge thanks. If you want to help me out the old fashioned way with likes and subscribing and whatnot I depreciate that too we're pushing for 2 000 subs now we're getting close so anyway bye for now we'll see you in the next video


curve is something which we have been using the term. So, this is Professor Kool and she has given those kind of curves and description and we on and off use it for the contrast enhance breast MRI. So, in the morning, Shilpa Ladman also told about the same and even ORADS we saw that dynamic evaluation with post contrast is important. So, basically you have to put in contrast dynamically you have to evaluate multi-phasic MR sequences and the early uptake is important followed by what happens to the contrast kinetics later on. So, two parts we have to see. So, there are three kinds of curves type 1, type 2, type 3. Type 1 curve is slow increase and persistent enhancement. So, this is very common with your benign lesions. So, only less than 9 percent of lesions are malignant and they have this curve. So, basically type 1 curve is towards benign entities. We are using this on and off for breast MRs contrast enhance breast MRI, but also again can be put up in other scenarios as well. Type 2 is plateau phase. So, initial uptake is there followed by a plateau phase. So, the uptake will be as compared to a normal area of the breast the uptake will be little early, but later on it will be like a plateau. So, that is again concerned for malignancy more than type 1, but less than type 3. So, most of the time these are benign lesions only and the last is type 3 the ones which we are concerned about the washout pattern. So, rapid uptake and rapid washout. So, that is a feature of neo angiogenesis pattern which is a pattern of malignant lesions. So, 29 to 77 percent chances of malignancy, but again if you see the percent is quite low. So, it is not sensitive not specific this is just an add-on as in the morning also we saw that morphology over enhancement pattern. So, you have to see the morphology first and then correlate the enhancement kinetics. So, we have to talk about two things slow, medium, fast initial uptake that is the first two minutes are important ideally 60 to 75 seconds and later on what is happening to that whether it is washing out or it is plateauing or it is persistently slowly enhancing and this is the angle theta which we were talking about in the morning also. So, this angle higher greater the angle that means faster is the uptake. So, rapid uptake is more towards the malignant side. So, type 3 curve. So, scan protocol wise you have to inject the contrast fast most of the centers still have hand injection which is fine because the amount of contrast in MR is not very much which we are giving, but the acquisition has to start quick and the first phase has to be within 60 seconds which you have to acquire and then multiple phases ideally 8 to 10 phases should be acquired and where do you place these region of interest ROIs. So, when you are documenting you have to place it at 4 places which is the lesion where you want to show what kind of activity or enhancement kinetics is there other area is a normal breast parent chimera to show the comparison. Third is air that will be a control means just like it is not a wrong analysis. So, it should be a flat curve when you are placing it in the air area and the fourth place is the heart or aorta just to show again a control. So, proper contrast injection has happened that will be picked up with this ROI in the aorta or in the cardiac chambers. So, basically three more important places and one in there as a control will give you ideal graphs and then you can comment upon the enhancement curves. So, this was about the cool's kinetics curve.


Here today to discuss something very important. Some might say it's the most important decision Shatter Squad will ever make. Shatter Squad needs a pet. Guys. We're not voting. I could build a little dog house for it, teach it to Fetch. Yes, Axel, exactly. He could be a basketball star. We could name him Scout. He would have one brown eye and one green eye. Yeah, okay. We're getting a little too specific now, okay. I vote Cat. Hi. They have knives for hands. And their purse lower your blood pressure. That's three votes for Cat. No, no, no. You don't each get a vote. Why not? Because you're the same person. Excuse me. We're getting a dog. We're not getting a dog. Or? Or a Cat. We tried this before and it ended poorly. Remember? We agree not to talk about Mr. Bubbles. You know that's a very sensitive topic for Tiny. I went on vacation for one week. One? We tried my best. It was a very tasteful barrier. Oh no. Not a single toilet involved. The disrespect. This is exactly what I mean. You're not responsible enough to have a pet. You can't even take care of your weapons. Excuse me? I fed and watered my weapon every day this week. West, we can do this. We miss our lives every day. I'm sure we can handle this. You want a pet? This is your new pet. Enjoy. End of discussion. Can't even get them to unload the dishwasher properly. They're going to clean out a litter box. I didn't even get to the slide about the outfits. We were going to have matching hats. I'm sorry, guys. Maybe next time. You know West. He'll come around eventually. We'll try again. We just have to re-strategize. Maybe we just have to find some cute pictures of dogs and just leave them around. Or something, I don't know. Yeah, I'm sure that'll convince him. Whoa, you have a what? How? Hang on. Does West know? Of course not. I found it's best not to ask for permission. Right. Ask for forgiveness, not permission. Oh, I definitely don't ask for that either. We just met, but I already love you. Good luck with all that. That's it. We're getting a dog, right? Just you wait. Was a kitten wearing suspenders really so much to ask? Dang. Thank you for checking out this episode of Red vs. Blue. If you enjoyed watching, be sure to check out the entire series over at Rooster Teeth. Danielle, let me see what you have. A knife! No!


Hello, welcome to this week's CMC markets commodity snapshot. This week we're looking at coffee coffee arabica But we're also going to have a quick review of how we were looking at copper prices And we're going to look at the chart patterns and the fundamentals involved in both of those Now last week we posed the question has the cuts in the reserve ratio in China put a bottom in copper prices So far the answer is to the affirmative if we have a quick look at the copper chart now we can see The prices are breaking out and they've they've overtaken the the 270 level and So this is a sort of confirmation of a technical breakout potential sort of double bottom pattern haven't taken place here and And we could be on for a move up to 290. Let's let's see how this plays out Now moving swiftly over to coffee arabica Last week we saw a massive breakdown in the coffee price And so what we want to see here is well is this is this move down sustainable or is this potentially even a buying opportunity? What's happened is that if you remember we talked in a good number of snapshot videos ago about the drought in Brazil and how that was impacting the production of coffee there's been a slight change up whereby That drought was thought to have sort of followed through an effective production in 2015 But actually we're getting a good amount of rain over in Brazil production looks Crop the crop production of coffee looks a lot stronger than others were expecting and so what we've seen is a breakdown in the 160 per pound in coffee on the chart and let's have a quick look at that now So this is a daily candlestick chart for copper and you can see it's really been this sort of 157 level That you've seen this this obvious breakdown where we saw a big bounce off it And then we've got a couple of minor bounces where price just wasn't able to bounce as high as that previous peak and eventually just rolled over and broke down and You know we're a few days behind the curve here, but if we do pull out to a weekly chart We can see that it's not just a sort of short-term daily phenomenon here This is actually a major long-term level that's been in place over a year now and coffee prices are at 12 month lows So if we to take this this longer-term range here, so the the peak 215 and this recent base at around 160 157 ish And then we project the whole whole range according to this breakdown We could actually get down to a dollar per pound in coffee With an interim sort of level of about a dollar twenty on that 61.8% Fibonacci extension Okay, that's it for this week's CMC markets commodity snapshot We were looking at coffee the data to look out is just the crop reports on coffee Just to see if the the reins over in Brazil are presiding over a bigger crop of coffee this year But we also got to keep an eye on this this 160 level see if that can hold if so We could be seeing further downside in in coffee prices and that obviously bodes well for all of us buying a coffee in the morning


Seven European Union countries order ammunition to aid Ukraine. Seven European Union countries have ordered ammunition under a landmark European Union procurement scheme to get urgently needed artillery shells to Ukraine and replenish depleted stocks. That's according to Reuters. Seven member states have already placed orders for 155 mm ammunition through the European Defence Agency's fast-track procedure. More orders, for instance, for national replenishment purposes could materialise in the coming weeks and months, the European Defence Agency said. The European Defence Agency said the EU deals were for both complete shells and for components, such as fuses, projectiles, charges and primers. In addition, the scheme covered four modern firing platforms designed and produced in Europe and most commonly used by the Ukrainian Armed Forces, naming them as France's Caesar, Poland's Krab, Germany's PZH2000 and Slovakia's Zuzana C2000. The European Defence Agency declined to name the countries or state the size of the orders, saying much of the information was confidential. In response to queries from Reuters, Lithuania and Luxembourg said they were among the seven. The scheme was set up as part of a plan worth at least 2 billion euros, launched in March with the aim of getting a million shells and missiles to Ukraine within a year. The orders placed under contracts negotiated by the European Defence Agency are for 155 mm artillery rounds, one of the most important munitions in the War of Attrition between the Ukraine's troops and Russian invaders. Until now, defence procurement has largely been the preserve of the bloc's 27 individual member governments. By placing orders before the end of this month, the countries are eligible for reimbursement from an EU-run fund, the European Peace Facility for Ammunition Procured for Ukraine, although Luxembourg said it would not request this. As reported, NATO has framework contracts for ammunition worth 2.4 billion euros, which cover 155 mm artillery, anti-tank guided missiles and main battle tank ammunition. This helps member countries to replenish their stockpiles while they continue to help Ukraine.


What's up everybody? Jason for Jasper's casebase.com 2021 in case football sells out Pikachu number one with this random number block Jets bucks Steelers Texans bills Packers you get a piece of these five teams or six teams. I should say Ran a number block style first number on the left side of sooner dash will we go by and again? It was just Douglas and then Dusty got the remaining nine So they go one two three four zero one two three four five six seven eight nine There we go. Let's roll the dice and we got ourselves a five minutes one six times Six times five zero one six one two three four five six Boom Dusty down a Dusty and let's put you right here in this one Then we got Six times here one two three four five six Boom six down to four six six Dusty with six and one Douglas with nine and does he have three eight zero five two seven four So coming up next is the break itself guys. Good luck everybody