Thank you so much. We're really excited to be here and to give this presentation regarding pipelines, optimizing pipelines and continuous delivery. So, put a little gender together for this presentation. And before I move on to the agenda, if anyone has any questions throughout this presentation, please leverage or ask the questions in the Q&A portion of Zoom. I'll be monitoring it as I'm going through the presentation. I'm going to go through a couple of concepts that may, you know, be a little overwhelming for some folks. So I definitely want to answer questions as we go through this. It's not rocket science, but you know, we were talking concepts and stuff so definitely ask your questions as you, you know, think of them and I will try to monitor this as best I can and then answer it in real time. So without further ado, let's talk about the agenda. So today I'm going to be discussing software development processes and life cycles. And that as they relate to continuous delivery. Then I'm going to talk a little bit about continuous delivery at scale, which is essentially flagging a few things that you should be looking for some of things that can go wrong when you're performing continuous delivery at scale. And finally, I'll spend some time talking about how you can optimize pipelines, make them more efficient, and some, you know, tips on how you can easily implement, you know, changes that will help you manage the efficiency a little bit better. So yeah, let's jump over to a quick introduction of myself. My name is Angel Rivera, developer advocate for Circle CI. So my role as a developer advocate essentially is for me to go out to the community and discuss, you know, technology and how folks are using technology. I'm also engaging at a grassroots level with developers to get a better sense of, you know, their bottlenecks with certain technologies, some of the struggles they're having, as well as offer up some advice on how they can, you know, fix those issues or resolve them. And it also serves as a really good kind of data collection for me and my team. And once I have those learnings from the community, I can bring them back to our teams at Circle CI. And we incorporate those learnings into our design processes for new product releases and upgrades so that we can bring better value and better features, useful features to the community. And so we're helping developers and trying to make their lives easier and learning what struggles they have is really helpful when we're developing features to help, you know, resolve some of those issues within the platform. If anybody wants to reach out to me. I'm pretty much available on Twitter all the time. It's the best way to get a hold of me. So if you want to reach out just hit me up at punk data on Twitter and I will respond accordingly. That's enough about me. Let's talk about software development life cycles and continuous delivery. Pretty exciting stuff, right. But before we jump into all of that, I wanted to kind of give you a foundational overview of software development life cycles what they are with what's what's their purpose if folks don't know. But it's essentially the rules for software development that teams and organizations develop and use them to govern how they build their software right so this essentially are the rules that people build for themselves and their software development processes, which then are you know, shared amongst the teams and then use as the guide to to building that software. So, you know, software development life cycles come in many, many different flavors. Right now I'm showing you two of the more dominant software development lifecycle methodologies used. One is called waterfall development, and the other is agile development waterfall development is the process where you know it's more of a cascading model and tasks are designed and then assigned to developers more in a in a bulk capacity. What I mean by that is if you look at the diagram for waterfall. That's dotted square box around those three elements within the methodology. Developers are given, you know these these tasks to complete just like any other job right you get your tasks you have to accomplish those tasks in order to achieve your goals within software development though in the waterfall development methodology. It's it's more sequential right so there's a lot of dependencies on getting a task done prior to moving on to the next task which, as you can imagine can create a lot of bottlenecks and blockage right because you're having those dependencies. And waterfall has been around for quite some time like I mentioned earlier. The problem with waterfall is it's very inefficient, especially when you have a huge group of developers trying to develop that software. You can imagine you know that cascading effect will trickle down and create huge inefficiencies in the software development process under waterfall back in the day. So developing software you know it would take us weeks months and years, sometimes to release new software, which is pretty bad for developer because you know you could be working on something. And a year later gets released and then you have to kind of, you know, shift your mindset to that previous context of a year ago, and you know to fix things or to make enhancement so, you know, I really didn't enjoy it. And you know, as developers and engineers we figured out that hey this waterfall development process is probably not the best for you know developing software, and we can do it more efficiently and that's kind of where agile development was born. If you look at that diagram you can see a lot of movement right there's arrows circles, but one of the key elements to or differences between waterfall and agile is agile actually breaks that cascading model. And implements a more of a, you know, smaller scope and concurrent tasks. So essentially right when you have a agile development methodology, you're building your software concurrently so your developers are working on smaller tasks, right smaller in scope. In order for them to like, you know, really focus in on the thing that they need to accomplish. And then they're continuously pushing changes right so you can see all those circles where you have a sprint. And then it just, you know, gets processed passes over to like a daily scrum and some scrum master in the center there is orchestrating all of this. Right. It's an incremental way of building software which is really, really nice because again tasks are broken down smaller you can be super laser focused on things. And you're not, you know, submitting huge code changes which could take, you know, a lot of time to review. But this is the software development lifecycle which I'll also refer to as software development processes so if you hear those two terms, they are the same. So, with agile kind of, you know, bringing efficiencies and optimizations to the way we build software. And the process or a concept within a process for your, your software development processes continuous delivery is essentially, you know, born out of these findings that, you know, we can do things concurrently, and we can deliver software much much faster. So, with continuous delivery, essentially, it was the practice of building and testing software, and then also delivering those changes to code and right changes to code and user environments using automated tools. So right with continuous delivery we noticed that the agile pattern of, you know, smaller socks work doing work in smaller scopes, and then also the iterative or concurrent practice of building software can be applied to how we deliver software. So you know those two methodologies, and then be bringing continuous delivery on that to kind of facilitate releasing that code faster. So within continuous delivery, though, we have another concept called continuous integration and continuous deployment. These two concepts are actually separate, but they're often, you know, discussed at the same time, which is kind of why you see it here and see this acronym CICD stands for continuous integration continuous deployment. And again, two separate concepts which are generally addressed at the same time because they are so inter-coupled and related. So, let's talk about continuous integration. It's simply the practice of merging all developers working copies to a shared code repository so what does that mean. Within the principles of CI, that means you're writing and committing code as often as possible, right, so you're committing code to a branch or some sort of repository trunk. And then those committed changes are shared and committed to a, they're committed to a shared code repository so that the reason you're doing that is your team can actually understand and see what, you know, how you're building the features in your code. And it's also a way for you, the developer, to pull down your peers changes and the stuff they're working on and understanding, you know, kind of where they're going with their code so that you can have that nice comfortable merge of functionality, especially if you're overlapped, right, and you're touching code in an overlap kind of sense. So, the other benefit or I would say element to the principles of continuous integration is you're testing your code on every commit. So this is adding a layer of quality, you know, from the developers perspective, every time they make code changes and then are committed, you're testing that those changes and then my favorite feature or benefit from from the principles of CI is the fast feedback loops right so as we're testing our code on every commit. We're able to understand or know if we have issues with our code because the tests are either going to fail, or they're going to pass or they're going to fail and if they're failing. You definitely want to know right as quickly as possible so that you can go back and fix those issues and then resubmit them right to the whole continuous delivery process. So fast feedback loops is one of the key benefits for me at least as a developer from CI. Now with continuous deployment. It's just a practice of deploying this new software or the changes that you created right and you're releasing it to your target audience target environments. There's more on the side of basically, you know, deploying software as as the name indicates. So with the principles of continuous deployment. We are creating release artifacts for continuous delivery or continuous deployment process. We're deploying code artifacts to those target resources could be a Kubernetes cluster could be just a simple, you know, somewhere that you just hosting the website whatever the target environment is doesn't matter but you do. The fact is that you're deploying these code artifacts to those those environments. One of the other principles is sort of like that at validation and services once everything's deployed. You could have a successful deployment but then your applications could be, you know, failing miserably. It's on the server that you deployed to so you know you want to validate that those apps after deployment or functioning and the services are, you know, executing as as expected. And then finally, in the CD, or the continuous deployment principles, you want to establish some sort of monitoring or surveillance of the state of that application to ensure again that it's functioning as expected.  You also want to monitor that to make sure that it's recovering and being resilient as designed. So, you know, with continuous delivery, CI CD, software development processes, all those things I mentioned are basically conceptual right these are things are guidelines that people define and then operate under, but none of it means anything without automation. And the reason I say that is the automation is what brings those concepts to life, right, they're the things that execute automation executes the continuous delivery concepts and plans that we make. So wait, I have a question here before I move on. So the question is how, how it tests the commit works for new features. Okay, so I think the question is. Let me let me rephrase this. So how does it. Okay, so, so when you're testing the new feature so when I get further into the presentation I think in a couple slides they're probably a little bit more clear. But what will happen is since you're running automation in your, you know, on your code changes. Part of the execution of a CI CD pipeline is running tests right so if you define that in your CI CD pipeline, like you know run a unit test or something it's going to happen every time code is committed and pushed upstream, so that you know you're not doing it manually on your laptop you just let the system do it. And that was, that was answered. So right getting back to automation. Again, you know, this is automation is what brings all of these processes to life. And we're going to talk about CI CD pipelines right so when you have your automation. Now, the. Sorry, we have another question. Testing comes under CI or CD, both my answer to that is both because CI pertains mainly to the developer side of things where you're like writing code. And you know you're doing that iterative testing, but then on the continuous deployment side, you also want to test and validate right so when you're validating something usually testing it, meaning deployments right security scans, maybe some regulatory scans and your deployment of patterns. So, the answer is both. But primarily if you're talking about code. It's generally in the CI process. So, we're talking about CI CD pipelines right and automation the automation itself is your. The mechanism right to execute with circle CI as a platform, that's what we are we are the automation that brings your, your, your, your concepts to life your continuous delivery and software development process to life.  And those are built upon jobs right so if you look at this diagram it's a quick snapshot of the circle CI dashboard and if you were to use our tool. This is what kind of what you would see with your pipelines as you can see right there's every every little box there is in this area is a job right it's a block of commands that perform a specific function. So if you can look, if you see at the left bottom boxes run tests and if you work your way up. We're building a Docker image and then right I'm also creating a Kubernetes cluster in this example, but you can see it's going to you know move from the left. To the right, as our pipelines succeed. So, once you have that set up right. The CI CD pipelines are really, really important for what I'm going to talk about next which is performing continuous delivery at scale. If there's any questions that there are some questions great. So before I move on, let me answer some questions here. So what are the tools. I guess what are the tools used in CD. So, in the context of circle CI for our continuous deployment. If you're talking about that which I assume you're talking about the, the tooling is pretty much anything you use right so if you're using an Amazon AWS CLI to deploy things to Amazon to Amazon. If you're using that cloud provider that's great if you're using Google's CLI to deploy to Google that's, that's also, you know, available and you can use that. You can use infrastructures code technology such as emphasis is a sorry such as Terraform or Pulumi or Ansible right whatever whatever tooling you want at circle CI we want to meet the developer where where they're at so you can leverage any kind of tooling you want within that because it's just essentially automation right. And then the other question here is. Is it a good idea to integrate or I guess integrate CD into production environments. Yes. If you ask me yes, you should be doing that. There's a couple reasons I mean you could still have your staging you can still have you know q amp a type patterns within your software development and release cycles. I definitely recommend. Excuse me, going in and do you know leveraging continuous deployment and production the reason is your production environment. You're never going to be able to replicate it 100% right no matter how much you try. It's just not going to, going to you know pan out for you that you're never going to reach parity. You know, obviously you want to control the way you deploy that and keep really good controls around how that's deployed, but I would definitely, you know, recommend you start looking at, you know, implementing a production level deployments because that's the whole point right is to get the code that you built to production as quickly as possible and as effortlessly as possible. And there's one more question here. So, I think both CI and CD needs feedback loop for automation. May I know your view of this. Yeah, so yes, feedback loops are exactly what is required to have a successful and efficient and consistent continuous delivery operation right so like the idea is to get things done as quickly as possible but you want to have quality built in right and by testing that helps ensure it doesn't give you 100% feels right doesn't cover all these cases but it will minimize the risk that you introduce you know some weird bug, because you didn't test so. So let's go ahead and move on. I know there's some other questions here. So my voice isn't clear I'll try to speak up. Yeah, let's go ahead and jump into continuous delivery a lot of stuff to cover here. So, with, you know, talking about delivery continuous delivery at scale. What I'm showing you here is a very generic. Let me get rid of that. Okay, so it's a very generic SDLC or software development lifecycle, like, I guess pipeline. And, you know, what CI CD mainly focuses in on in this SDLC example is generally going to be in the development testing and deployment phases of your processes right. And this is where marrying CI CD and and into your software process development processes is really important. And most beneficial I should say as well, because, as we all know right code and repositories grow over time. And that's where I'm talking about, you know, the complexities growing the volume of code grows. And on top of all of that, you know, all of those things, and be able to, you know, address them as soon as possible because if you're not maintaining that growth, it's going to eventually like bite you, right it's going to impact you negatively. And establishing and maintaining mechanisms for scaling, you know, that provides solid support for pipelines is very difficult to achieve without constant surveillance and interactive reviews, meaning, you know, constantly going back and checking are our processes, you know, kind of matching our, our continuous delivery processes right. So that happens.  And that can get you into some trouble as well. So when your processes are not properly aligned.  You can also substantially hurt your quality right of the code. One of the things that happens here is if you're looking at this diagram. I'm showing you like you know the development phase things are kind of out of whack they're not really properly aligned with your software development processes or your guidelines. This happens a lot when teams are interested in kind of, you know, not working in a controlled process. It does happen occasionally amongst teams and within organizations that, you know, your software development processes don't exactly match up with your continuous delivery processes. They're like, you know, everything's kind of out of whack and in different layers. So but I'll be talking about that aligning these in a little bit here so. So, right when you have these misaligned CI CD segments that starts to introduce confusion among your teams like who's doing what when are they doing it why isn't the automation reflecting this, because again, you know, your, your CI CD or continuous delivery cycles or pipelines are a reflection of your software development practices and they, well they should be at least and when they're not aligned, it will diminish the quality of the code. You'll actually waste a ton of cycles development cycles which is very expensive because again developers are, you know, very expensive they're the most expensive piece to building software in most cases, and then it will definitely slow your relay cycles down dramatically. One of the other things that when you're operating at scale is directly attributed to the platform CI CD platform effectiveness so again the CI CD platform that I'm addressing here, or at least an example is circle CI. That's what we do, we provide the automation we are the CI CD platform for your for your pipelines. And you must ensure that you have a platform that's very robust very resilient, and that can scale CI CD platforms come in many different flavors, many different companies. They actually select, you know, circle CI we solely focus on the continuous delivery pipeline, whereas other, you know, platforms, they may be more of a all in one solution and CI CD features are kind of bolted on. And they feel kind of bulky and slow and it's actually really not their primary focus.  The performance if they're not scaling properly or being very resilient or robust can can kind of hurt you in the end. So one of the advice I give you is to look at your CI CD platforms evaluate them make sure that they are, you know, filling the needs that you have for your CI CD pipeline and are able to scale with your workloads. So as you grow more members on your team, you know, the infrastructure needs to also be able to be resilient robust and scale with your workloads. So, one thing I will say, you know, teams really must understand that reliance on CI CD tooling and execution is essential and will increase dramatically further.  And if they're not working properly and you know you don't have CI CD capabilities for your team. It's going to cripple your productivity.  And one of the like huge efficiency killers is when your CI CD platforms are not working properly, you're going to be in a world of hurt right as a software developer as a software development team. So, I'll stop here to before I jump into the next section. Let's look at some questions, which programming language would you recommend for the automation. Oh, that's a good question. I have reason why. Yeah, so so right we're all developers. The reason why this is a good question is, in general, most the ICD platforms have settled on and this isn't quite a language it's a data structure in order to define your software. Sorry, your continuous delivery pipelines, the language or the sorry, the data structure the syntax that we use is called the amel. And I'm sure if any of you have worked with any more modern cloud native type systems or solutions, you're probably quite familiar with what the amel is which is the data structure, but we use it's a it's a human readable very highly declarative data structure that we use to define things and one of the cool things we can do with it is define commands right so it's a nice. It's a good text to use human readable. It can get quite verbose and wordy, but at the end of the day, it is what we use today, and actually, most CICD modern most modern CICD platforms are defining your pipelines within the amel. The next question is, are there any approval processes in this pipelines. So, generally, you don't want to have that right manual intervention in any pipeline, but there are situations where you need it right so like if you're in a regulatory space and you need to have some eyes on a segment or a job where you can continue, and you need that manual approval. Yes. At least that circle CI we have an approval process, you know, we call it an approvals job, and you can set that in your pipeline at any point you want to see, you know, some you want to stop the pipeline until someone manually can look at it, and then let it go, you know, click the approval and it'll it'll proceed. So yes, there are approval processes. Next question, do you have any numbers regarding the performance of your machines versus the ones provided by Azure DevOps. I believe there are internally there are some some numbers I don't know them I don't have them. But yeah, we're, yeah, we probably have them. If, if you want to have a further discussion on that either hit me up on Twitter, or on our discord site and we can see what we can do to see if we have some metrics we can share, but I'm not sure where that lives. So, the next question is, except, except static code scan security testing. Are there any other security features that we can implement in CI CD pipelines. The answer is you can implement at least in the circle CI platform you can implement pretty much any kind of security. You know tooling or features or processes that that you work with. Again, you know, circle CI is designed to build to meet developers where they are so we enable you to run pretty much whatever you want with within reason on in your in your CI CD pipeline run times. So whatever tools you're using right now. And by the way that that's pretty much true across the board with with most, most modern CI CD tooling. There are limitations and restrictions but in general yeah you can pretty much run whatever you want however you want within those platforms. Is there the next question is there a best practice around making builds for different target OS environments in the pipeline. Yes, there are. So, you know, it depends on everyone's case is different but there are some common guidelines right that you can use to to build things. You know, obviously when you're building for different architectures so to speak like let's say you're building for x86 or arm which is what we introduced recently as well, the capabilities are there to now natively build, you know, software for those two architectures. It's definitely something that's like, you know, again, you can do it many, many different ways. But I would say that, you know, doing them efficiently is very important. So, you know, putting an emphasis on optimizing those build processes so that they get done as quickly as possible, but you can implement pretty much whatever kind of build process you want for those architectures. So, let's go ahead and jump into optimizing pipelines I think answered all the questions. So, what I mentioned earlier was, you know, Circle CI or not Circle CI but continuous delivery is is really important it's critical mission critical for development teams to implement this and ensure that you know their pipelines are running efficiently. So, the one of the main reasons is as I mentioned earlier right, you don't want to waste any developer cycles meaning you don't want humans sitting around waiting for, you know, feedback on the co changes that they're making, because your maybe your system is down or whatever, and the reason is, you know, we've calculated that the average cost of developers time per minute equals to about a buck or a dollar and 45 cents right every minute. So imagine if you had to. If you had, let's say, I don't know 100 developers sitting around for 60 minutes because your CI CD pipelines or your platform is not functioning right as it's down. And the developer cycles wasted is devastating. So it's in and can get very very expensive so you know with that in mind. Optimizing pipelines is super important, but you might be figure asking yourself like okay so how the heck do I, you know, optimize Angel how do I, what do I look for, and I'm going to touch on a few things. One of the ways that, or one of the like easy ways to become inefficient or or your pipelines becoming very slow and and not really in clunky right not really streamlined is again by what I talked about earlier is having misaligned CI CD segments with your software development processes. So remember this diagram. I was talking about how everything's kind of jacked up right not really aligned. But this is kind of like what you want to see moving forward you want to see that your development processes are properly aligned and executing in accordance with your guidelines right. So testing debugging all that good stuff. And that's where you can put like, in that phase security, you can do things like submitting and pushing and deploying your, your, your artifacts, like maybe QA, or staging, right you can do all those things within that phase of your software development lifecycle and then finally rate deployment, which can mean many many things. At this point, we're just going to deploy to production. Now if you notice all these things have a circle with arrows around them to indicate movement and iterative right processes so these things are happening all the time and every time code changes. So again, you want to make sure that you're aligning those bits with your software development processes so that they're just simply running efficiently and also as designed right within that higher level software development process. One other way to optimize pipelines and this is a, this is kind of a thought that I had a couple years ago, I noticed just with my engagements in the community that you know there's a lot of people talking about how there's gaps within their software development teams or release teams. You know, they're, they're just not gelling very well and you can throw DevOps into the mix as well where you know that concept there is where developers and operations teams are working kind of simultaneously and understanding each other's roles. And that is, that's a really hard adoption and implementation to make and it's never the same across the board for any organization or team. But what I'm proposing is, or what I've proposed in a blog post which I'll share the link to later is this concept of a continuous delivery engineer, and I know our industry doesn't need another role right or another, another title. I really believe that a continuous delivery engineer is kind of going to be the future. And this is why right so like in the blog post I just, I describe a lot more detail which you can read later, which I'll share that link but essentially there's two characteristics here that I define. One is the kind of the human element for this role like things you want in an individual to that's in a continuous delivery engineer position to have is like strong communication skills. I think you want that in every role but it's really important for that for this role in my opinion. You want them to have a keen analytical skills which means they're able to understand, you know, identify and understand patterns, so that they can, you know, decompose those complex patterns and processes and describe them proficiently to folks who are not in the industry right they could be business stakeholders, or people like that right outside of the software, or the technology kind of schema. You also want like proficiency in automating and optimizing these processes right so that you can also build confident teams and maintain that that rapport with your teams right so they're all kind of tied together. And it's essentially those characteristics are really important to be successful in this in this position. On the right side we have some of the duties that I would imagine, you know, this position to have. Obviously, you are essentially the CICD czar, so to speak. So, you know, you would be responsible for developing CICD principles. That involves, you know, touching the higher level software development processes and collaborating around that stuff to ensure that you know your product your software development process are direct reflection of your, of your release cycles or release processes, as well as review and modify CICD principles, iteratively, iteratively right so meaning just don't write the principles and guidelines that you're going to operate under but go back and check on them often. Also right you're going to maintain the tools and platforms.  So with continuous delivery engineer again it's just a role, something you may want to think about implementing inside of your organizations. So with technical optimization strategies, what I described previously was more of the human elements, and what I'm going to describe further are more, you know, the technical aspects that you can look for and optimize as well. So one of the main things I noticed that developers in general like this is a common problem in the industry is the lack of knowledge of their, the languages frameworks and resources used in your text in the tech tech sacks right so having proficiency in those languages is really important and understanding the capabilities and limitations of these languages frameworks and tooling is also critical. Because when you know how those things work, you have the ability to kind of quickly understand when when things go wrong right like why things are going wrong. Like, you know, if you're having performance issues, the code is running slower, you have an ability or at least some insight into where to look right to troubleshoot to figure out why is, why am I experiencing this performance hit, or maybe you know even bottlenecks sometimes the software just, you know your data out grows the software happens in a couple languages, your data sets you know that you're you're transacting on within your languages are just too big. And in some cases, you know, most languages frameworks have this ability to run things, again concurrently right so they have these concurrent capabilities. So you should be aware of these native concurrency capabilities within your stacks to actually implement them when you need to right so if you're if you're, if you're seeing like, you know performance hits. And, and, especially like I see this a lot with testing, the test suites, you know, as they grow they become, it takes longer and longer to, to run the test suite because you're getting into that whole situation where you know you're cascading so like you have to wait for one test to finish, and then move on to the next. In most cases, you don't have to do that you can, you know, implement the, the native concurrency capabilities in the stack, and then run all of those tests at the same time. This is similar to like the multi threading concept right.  Without even having to tweak a pipeline which is really important, because this is like a localized change. Now, what we're talking about next is tweaks or not tweaks but concepts within the CI CD pipeline concurrent job execution is one of them. It's huge. You know, you have to ensure that your, your jobs are running simultaneously wherever you can. It's not always possible, right to execute a job without a dependency, but if you can run and orchestrate your jobs to run as, you know, at the same time wherever possible do that, because that's where you kind of gained that velocity within your your CI CD pipelines and release cycles. Avoid building job dependencies. Again, you know, what we talked about like in the waterfall example where things are like dependent upon each other right you can't start a new top a new task. And it kind of ties back to running things concurrently. Avoid any kind of build dependencies if you can wherever you can. Again, there's going to be places where you need to, you know, have a dependency like you have to stop a job, or you can't continue until a previous job succeeded. In some cases it's a security scan right so you don't want to deploy, or you don't want to move down your process. If you have some vulnerable code that maybe has been detected right in one of your jobs. So you know, again, avoid building these dependencies wherever possible within your pipelines, but when you have to build those pipeline or those dependencies. It's okay, right, but this is the general rule that I like to go by and suggest. Let's talk about caching right so caching is is, you know, the ability to basically down a bunch of files or dependencies or code or whatever. One time and then update things only that the things that change. It's super helpful. So we know when you're when you're running pipelines because the least amount of things you have to download the faster your pipeline is.  There's a couple cases where you know you're pulling down software, and you're pulling down all the software all the time that's not caching. I've seen that quite a bit. And then you know it's a problem, but then we're going to go ahead and talk about, you know, only update the change dependencies within your cash that's that's the proper way to implement caching is you know, the first cat the first run of your pipeline will only download all the dependencies. And then from there, you know subsequent runs of that pipeline will only update the changed dependencies or the changed files in your cash right so you know keep that in mind when you're implementing cash because it can, if you're not implementing it properly, it can cause, you know, a huge reduction in velocity in your in your pipeline. And the other, this is a this is more of a tweak right so if you notice like your pipelines are running on compute nodes everything that you do in a CI CD tool is running in a runtime on a compute node, depending you know it doesn't matter could be a server in a data center could be, you know bare metal server in a data center could be a virtual machine and Amazon whatever the resource classes in your CI CD tooling.  One of the biggest things I see is, you know, people add more code, things run slower, and then they just don't do anything about it, they continue to use the same compute node size. And when you do that, it's costing you money right because you're slowing things down. Now, a lot of folks don't want to upgrade or, you know, to a more capable or more capabilities on their compute node, because they fear the cost will you know be astronomical. I can tell you that that's not the case all the time. Actually, more likely than not, you will experience huge astronomical increases. So think about it this way when you implement a faster compute node things are getting done faster. So that's shortening the amount of time you're using that node. And you know, it could, I've actually seen it be cheaper to run and on a huge node right then running on a on a slower, more, you know, the cost consuming node.  They have the proper capacity. So test execution. This is really important. You always want to be testing your code right. There's no question there. But you also don't want to, there, I believe there's a there's a thing is such as over, you know, kind of overkill for the test. And what I mean by that is, you know, if you're in the development phase, you don't want to be running end to end testing all the time right on changes that you're making every time. So what you want to do is scale that down to and scope it out to more of a unit test type execution you want to make sure that those tests are super fast right and keeping the developer going now if you promote that that that bill to a something was it. Yeah, if you're going to like a staging or QA, then at that point you want to run more extensive comprehensive tests, they're probably much longer, right to run. So you know just just keep an eye on when and how you're running your test. And actually there's one more other thing. Make sure that you're running tests that add value. So you know if you're testing something and every time you run that test. It's green all the time, you should probably look into that test and add, you know figure out like it's just adding value, because it's always green all the time, is it even functioning properly. So you know those are kind of things that you need to check out when you're running test execution. One other thing I want to talk about is conditional job execution. And this is basically how you orchestrate your jobs right. So, again, going back to that, that example of like maybe you're in a development phase of your code. Do you really need to run a certain tasks that pertain, maybe to promoting things to production or to Q&A type, you know, elements in your in your software processes.  So again, if you're just, you know, performing development of new features, scope those job executions a little bit better so you're not like, you know, doing full blown promotions across the board for no reason. You know, that that I see that all the time and it just adds more and more time to your overall pipeline run and then slows things down quite a bit. You just want to run those when certain conditions exist. And finally, I want to talk about set setting a bill duration target. So this is essentially like every, you know, every pipeline is composed of many jobs. What I mean by this statement here is you want to ensure that every job that you run is being run optimally and within a certain timeframe. So by setting a goal, I personally like to set a goal of 60 seconds. It's aggressive. It's unrealistic. But, you know, we need to we need to set these aggressive unrealistic goals so that whenever we see a job right going over like for me if I see a job going over 60 seconds, you know, then I it's a red flag, and then brings my attention to it, and I can look at it and see what is going on right analyze why is this taking longer. And you know it's like a troubleshooting kind of flag. But again right you want your pipelines to be very concise very, very fast right because you're the rest of your, your release is depending on that your release cycles are depending on that on that quick velocity right so set your build target, build duration targets, very aggressively. Now of course right if you're sending jobs off to like Amazon file build or something like that. That's out of your control. So you can't really you know if it takes three minutes, it takes three minutes but at a minimum you know that that job is taking three minutes because it's out of your control. By the way, again, if it's, you know, the threshold is exceeded that three minute average is exceeded, you need to look into why that's happening right.  So that's basically all of the optimization bits. I'm going to go ahead and recap and then I have some questions which I'll stick around for even if we go over a little bit. I'll definitely answer those questions. So let's go ahead and recap on the optimization of pipelines, align your CCD segments with your software development processes really important to keep those nice because again, your continuous delivery processes are reflection of your software development processes, establish, you know, if you can establish a continuous delivery engineer or at least look into that kind of role. It's definitely, you know, like I said, continuous delivery is being adopted by pretty much everybody. It just makes sense to have like a central team or central role that's kind of overlooking and overseeing and managing all of that for your teams. You know, understand the languages and frameworks and tooling that you're using have a deep knowledge of those things because proficiency in those technologies will help you learning, you know, knowing the capacities, the limitations of frameworks will definitely help you, you know, in many aspects. Execute your workloads concurrently. That's always a motto that I've adopted years and years and years ago, and I try to execute that at every turn. Avoid building job dependencies right. Like I said, there's going to be times where you just can't do it. It's just, it's impossible. You have to have a dependency, but wherever you can eliminate those. Please do so. And trust me, your life will be so much happier and faster. If you implement that, that advice, use the cash cautiously right and only update the change things.  And then finally set those build duration targets. You can use my number if you like 60 seconds so you can build your own, but the lower right the number, the faster things complete. So I think that's pretty much it. I just wanted to share this link, which is basically the state of the software delivery. So it's a thing with the report that we've been releasing annually for the past couple years. And it has a lot of data on how to benchmark yourselves, as far as like, you know, metrics on what a high performing team looks like, what kind of recovery developers are facing and this is all data based off of the usage on the CircleCI platform so it's pretty accurate we do millions and millions of builds per day. So like, you know, we have a lot of data and we're finally, you know, making sense of it all and releasing it to the public so that they can understand how they can improve their release cycles. The CICD engineer role that I talked about, if you want to read that blog post, just use this link. And there's actually another follow up piece to this that I wrote. So it's been about a two year project but at the end of the day I update it every year with some more thoughts and stuff so you know if you want to get some more detail, go ahead and check that out there. And finally, if you have any questions that I didn't answer here, join our Discord server. And in there, you know, CircleCI developer advocates, the rest of my team is in there, and we're generally answering questions or you know, talking with folks as well. So it's another way for you to connect. And that's about it for now. Let me answer some of these questions that are in the queue, and then we'll finish this thing. So, one of the questions is, can we implement all of the CICD tools in Docker, if we implement that, what are the pros and cons. So, like, you can use Docker within the CICD tooling I think that's the question. So can I use Docker within the CICD tooling. Yes. That's one of the, what we call executors, which is that compute note I was talking about. You can use Docker images, you know, build your code on Docker images in CircleCI that's not a problem it's actually encouraged, especially because developers right they're using Docker more and packaging their apps up. So yeah, you can definitely use that. And the pros are that right it's it's the same workflow doesn't really change for you you can use the same Docker file same code. The pros are there are limitations right so it is a Docker image or Docker container. There are performance issues as well.  The next question is, can we manage the pipelines and jobs as code without setting up everything using the UI. Do you have any recommendations for tools and practices. So, yeah, so there are many tools out there they all do it do do the CI CD pipeline definition differently at CircleCI like I said, we use YAML most tooling uses YAML.  If you want to SSH into the box you can do that with CircleCI select the developers can, you know, debug in the environment where it failed versus oh here's a bunch of logs, and that really don't make sense, and then you try to debug on your local machine which is nearly impossible, or it takes a very very long time so yeah you can do that within CircleCI for sure. Most other tools also use, you know, depending on the tool, but you know a lot of them have that code capability to define your pipelines, and you don't have to jump into a UI. So the last question I have here is can you elaborate a little bit on avoiding job dependencies in concurrent job execution. Yeah, so avoiding job dependency so a job dependency would be let's say you have a manual approval step right. Like let's say your pipeline's coming along and it has to stop because you have a rule that says a manager or some you know person with authority needs to look at the state of the release at a given time so maybe you have a Docker image that's going to be deployed to a maybe a production environment. The dependency there would be that that approval step right. You actually absolutely need that because maybe like I said you're bound by law via compliance the regulations right. So that's a dependency now where you were I'm talking about where you can eliminate that is anywhere else you don't need that just run things, you know, concurrently, like, okay for instance, in my pipeline I usually build using infrastructure I build a Kubernetes cluster so that the release that I'm working on can be packaged up into a Docker image thrown or not thrown but deployed into a Kubernetes cluster, and then I can run some smoke testing you know to make sure that deployment is legit, and you know to verify that that Docker image works in a Kubernetes cluster. Now, most people will do things like, you know, build the cluster and then obviously you can't deploy this built image until that cluster is created right so that's a dependency right that you cannot break you need the cluster before you can deploy, but all the other things like running unit tests running security tests, building the Docker image and the Kubernetes cluster at the same time can be accomplished concurrently right. So that's what I mean by you know eliminated because a lot of people wait for the cluster to be built, then they'll build the Docker image, and then they'll deploy the Docker image. What I'm saying is now just do everything you can as you know quickly as possible because if one of those fails, then the pipeline will stop. And then you know you have to go back and figure that out. So I hope I answered that question regarding pipelines. And I think we're out of time right. I think so. Okay. So I don't see any more questions. Thank you everybody. Thank you so much to Angel for his time today and thank you to all the participants who joined us. As a reminder, this recording will be on the Linux Foundation YouTube page later today. We hope you're able to join us for future webinars. Have a wonderful day. Thank you.


My name is Hannah Judin. I'm the deputy secretary general of the Swedish Left Party, Vänstöpartiet. I would say that the main problem, the main far-right problem, is today actually the Sweden Democrats. They are represented in the parliament and they have grown enormously the last years. They are the main problem and of course we have smaller, really extreme Nazi fractions but they are not in the parliament. I think there are several reasons. I think that they have been really good the far-right of exploiting the huge income gap and the huge growing inequality in Sweden and in other countries. They have been good at this and they have pinpointed kind of scapegoats and what they are doing is that they are showing this and people feeling a bit worried about these things and they are pointing towards immigrants or feminists or Muslims. It's an easy scapegoat. Firstly, we should never ever accept their narrative of what's wrong in society and their solutions. We must remain proud of being socialists, feminists and anti-racists. But we should not ignore the problem that they are kind of exploiting. We should try to find solutions, other solutions that unite people and I think those solutions should actually be on economical issues mainly. I think we live in a very interesting political time where people are really getting more political. Just look at kind of the young movement, the climate change movement. It's being politicised society today and I guess we are going to see more and more of these uprisings about social issues, movements and of course if you are not willing to join a political party I think you should take part in those kind of movements. The left has a real possibility today. Of course you can feel depressed about the developments with the far-rights in almost all countries but for the first time in a long time people are questioning neoliberalism and people are saying the system doesn't work. Just look at the environmental movement. They are saying we must change the system. No one else has an answer to this than the left so we have a real possibility here but we need to stay proud of being socialists and we need to have real solutions to real problems.


On Monday, oil fell after Saudi Arabia and Russia delayed their meeting. HeroZone construction activity fell at the fastest rate for over 11 years. Japan launched $1 trillion coronavirus stimulus packages. Prime Minister Abe announced state of emergency. In China reported 39 new coronavirus cases as of Sunday and saw a rise in asymptomatic coronavirus cases and sit with tightened controls at land borders. Welcome to the Tick-Mill Update, I'm Kiana Daniela, founder of the Investeva movement. Make sure to subscribe to the Tick-Mill YouTube channel and support us by liking and sharing this video with your forex trading friends. On Monday, the US dollar and the Japanese yen underperformed their major counterparts as the market mood notably improved. The S&P 500 and Dow Jones were up over 7 percent, boosting the sentiment linked Australian dollar and New Zealand dollar. This was probably because some were stabilizing coronavirus cases and additional US fiscal stimulus back. Today I'm looking at the ASEAN hair, which despite the recent bullish momentum has still been not able to break above the 67 resistance level. However, on the 4-hour chart, it has just broken above the Ichimako cloud, which could be an indication of continued bullish momentum towards at least 67, which also falls on the 50 percent from the Nasu tradesman level. Any bet further than this would be too risky in my opinion. The same pattern is observed in Aussie dollar, Kiwi yen and Kiwi dollar. Now do you think these pairs will continue their bullish momentum throughout the week? Head over to the comment section and let me know. Of course, trading in financial markets involves a risk of loss and you should only trade the money that you can afford to lose. If you like this video, give it a thumbs up and subscribe to the Take Mill YouTube channel. I'll go back to you with more updates tomorrow.


Hello, I'm Lieutenant Colonel Emerson Bird, the Chaplain Account Manager for TRADOC. Are you looking forward to a change in seasons? Summer will be here soon, and I don't know about you, but that usually means a change in gears for me. It is often a time to travel, enjoy the outdoors, and visit family and friends. While we are still in the midst of another kind of season, one that has been prolonged, uncertain, and sometimes lonely, what can we do moving forward? What about making connections a priority? What about seeing family and friends that you've been missing or gathering with your family of faith? It just may be the part of this summer that fills your cup, and theirs too.


Thanks so much. So I was asked to come here on Wednesday, so I was thinking what what's missing here What could I add and I wanted to talk to you a little bit about fundraising from the entrepreneur point of view Last year at slush we announced our latest seed round for Company echo founded sudden coffee. We make instant coffee. That tastes really really good and We're basing San Francisco And today we've raised three point four million dollars from a variety of top tier VCs Including white combinator. We were in the winter 17 batch earlier this year and Charles River ventures and and the local Lifeline ventures year and I thought that it could be interesting At least for me to actually see how a pitch That sort of raised this amount of money might look like so I thought of of giving you the pitch and Sort of a little bit of background. I left sudden a couple months ago Company still doing really well my co-founder is running and and and I'm still as a shale holder involved and Yeah, so here we go So basically here's the thing everybody loves good coffee, right who here doesn't like good coffee Now few love instant coffee I mean This is the sort of gnarly stuff that you end up getting in airplanes when you're waiting at a dentist office and so on It's basically just liquid coffee. That's dehydrated But here's the thing instant coffee is the king when you look at the coffee market. It's a 35 billion dollar market Imagine that out of the 85 billion dollars that coffee is worldwide And there hasn't been any innovation in the past what 50 years basically since Nescafe came out Then on the other hand The consumer interest is trending heavily towards the high quality specialty coffee That's sort of in here as well. That's the sort of much more differentiated much more interesting Approach to coffee and on average the millennial consumers spent $80 in coffee per month, which is a lot of money Now here's what we wanted to make Instant coffee that you'll actually want to drink. I was sitting on a plane I was really desperate for some caffeine and I had a coffee and it was horrible and I thought is there a way I could have good coffee right here So why not make instant coffee that would actually taste good. It's basically liquid coffee. That's dehydrated So we approached it by making taking good coffee brewing it well and not screwing it up, essentially so Basically it's about combining the convenience and all the good things of of instant coffee. It's super light has a huge shelf life It's cheap to transport easy to use designed to scale with all the best aspects of specialty coffee great branding great taste high-margin and that it's growing rapidly and As you can see it's like two huge markets overlapping So far we have customers who absolutely love it. We have an amazing amount of basically shares in social media and The the demand is showing pretty strong organic growth now redacted the numbers But these are still the sort of graphs are actually what we had in the pitch and We also have a really good team my background is is heavily in coffee before I got into startups I ran a bunch of coffee shops at slush three years ago We served all the coffee that was served here about 22,000 cups Throughout seven seven cafes throughout the event and also studied food science at University of Helsinki Then my co-founder Josh is Stanford industrial engineering grad We spend a lot of time at McKinsey optimizing factories and we have a scientific advisor who's basically the world's leading coffee scientist Who is helping us making making good coffee? He was the head of taste and aroma at Nespresso, which is a pretty cool title Now that was basically the pitch we pitch investors When we raised this about 2.7 million round and for our first round which was half a mill It was basically the same but with fewer numbers But the the market was market research was same and the the validation for the product was same now keep in mind that This is sort of my experience is limited to this one one company and one race when it comes to raising money for a startup So the end is is one and also I think that a really important thing to keep in mind when you're an entrepreneur is that You know your company best People will give you advice you can hear about things but take it all with a grain of salt Nobody has the full context on the company the same way you do I've been screwed many times when I listen to somebody who doesn't really know what they're talking about But they're really confident in saying like oh you guys should do this Absolutely, and then it turns out to be a horrible horrible idea And now I think I want to sort of try to deconstruct this and share some of the factors that I thought made this a successful race and I think the three quick three key questions that we knew investors would be asking and and that we wanted to answer were basically is What you're making something that a lot of people need or want ideally need and this is basically is there a market for what you're doing Is it something that a lot of people love and want to pay for it? And at that point we Basically, this is the market once I show this slide. Nobody's questioning if there's market for specialty coffee Or specialty instant coffee where there's two huge markets We have a product that's overlapping We're first to that market and I don't need to put a number there Anybody can figure out that any sort of overlap will probably pretty pretty significant and then secondly is basically second parties to traction so When you're raising money for a company the best way to raise money is to make your company better So the more traction you have the more sort of confidence that builds in your ability to execute and Sell that product and also prove that people like what you're doing And in our case for the second second raise we had been Shipping product for about a year and we had very sort of strong organic growth Secondly You want to answer the question why is your company in the top 5% in the world to solve this problem? Why are you the best team to solve this problem? Early-stage startups are essentially a function of its founders if the founders are great They can probably overcome a lot of obstacles and barriers and make things work You can have a great idea in a mediocre team and it'll probably turn out to be something mediocre Or you can have great founders And an okay idea, but the great founders will probably turn it into a great idea sooner or later And in our case, this is a photo from my first barista competitions I've I'm a two-time finished barista champion before I embarked on my startup career and and was ranked as the ninth best Barista in the world and then also I've been involved in slush since 2011 and also studied food science And then we have my co-founder who is a really like incredible operations geek and amazing at optimizing Sort of physical production environments And then we have this scientist who is the world's leading authority in figuring out how to build something like this So it's a team of very sort of complimentary overlapping skills that a Lot of investors said that that's basically like why they wanted to back this Since there's sort of strong proof that we can make this actually happen And I think thirdly is why what prevents from somebody else doing this. How is this defensible? And in the case of sudden sure Nestle could do this, but they don't know how to market it We sell it online as a subscription to consumers in the US Which is very disruptive in the instant coffee space And sort of a lot of people wouldn't realize that so it's a combination for us of combination of factors of it's very It requires a lot of skill. It's hard to make it. It's hard to scale it and the barrier of entry is fairly high So that's also something you'd want to bring in And then I think some sort of more tactical General tips for fundraising based on my experience and what I've seen and learn at Y Combinator And this is something that I really love and I'm a really big fan of being positively weird And by that I mean something that a VC or an investor who sees a hundred pictures a day at best remembers and in our YC batch there were 112 companies, I think and I could bet Quite a bit of money on it that we were probably one of the most rememberable ones The guys that make instant coffee that looks kind of like drugs So you want to take advantage of that Sort of being positively weird in a good sense It makes it easier for people to talk about you for other people to pitch you I Can give somebody a tube and say like this is our instant coffee and you can give it to others It's really easy to remember you can go to somebody's office and you see it there like oh, what's that? It's really hard to do that for a you know your regular B2B SaaS app You can usually find a way to do that and if you can I definitely embrace that as a key differentiator And then basically fundraising is about creating FOMO. So if you're missing out Momentum is your friend. That's what you want to build and so at YC They Recommend you To say no to all investor meetings and say that we're just heads down building our product Because the best way to raise more money is to make your company better the more attraction you have The more track record you have the better the more paying customers you have the less money you need to race and so basically Not taking any investor meetings and then having a like a week or two week period where you book all the investor meetings back to back And you become you work on to become the hot new deal in town The one that everyone's talking about and I read this quote the other day that nowadays All the deals are That was it so basically They're really under subscribed until they become hugely oversubscribed So nobody wants to be the first to give you the money, but once you have somebody everybody wants to be in So it's about creating that momentum and creating that FOMO for investors For the deal and that can sort of really make it a much more shorter and efficient Project for you to raise the money so you can get back to what you actually want to be doing which is building your company And then lastly you're only looking for a market of one. Yes You basically most of time need that one investor who's gonna say yes There are a lot of companies who've pitched to a lot of investors who've said no so many times until they find one company and Become a huge success. So don't give up keep going Good luck. Thank you from Slido So the first question from Daniel is how difficult is it to copy the product and enter the market maybe outside of the US? I would say that It's pretty hard to copy the product. We worked on it for a very long time Part of the proof is that nobody's done it yet at least nowhere near as good as ours is and So I think it's definitely doable and and I don't think it's When you're creating a new market with your product, which is basically the case for us we're the first premium instant coffee that is on the market and It might sound a little country-intuitive, but at some point you do want competitors as well Because that validates the market If you're first to the market and then all of a sudden, you know Like Nestle and all these other big players are coming to the market That's amazing validation for you that proves that you've found a market niche That these other big players realize can be a big thing but at that point you're also so far in the product development that you have a huge head start and You can keep iterating and owning a large proportion of that market when the big boys are basically Growing the pie for you is is is how we think it but it's not something that we're worried about and again One of the sort of YC mantras is that startups don't get killed They they commit a suicide most of the time So the vast majority of startups don't die because of competition or sort of external factors But because the team falls apart or something else happens What did I go to be us? so It was a variety of factors partly because I really wanted to get out of Helsinki and and not Living in snow, so California see a loop for lucrative San Francisco is a great hub for technology and coffee both and I knew that we need to raise more funding than would be available for us here. And frankly, there's not the type of technology in terms of food Science and so on just available in the Nordics Although it is in the US and that's again one of the one of the things of being positively weird being in San Francisco is Is the fact that it's a tech company? It's a it's a tech city and then all of a sudden there's this coffee company That goes to I see and make these tubes of coffee We have a factory in San Francisco and and it makes it sure it's a little more expensive than somewhere else But it makes it so much more rememberable and so much more interesting It's kind of like a juxtaposition which is a great when you're pitching it to journalists for example So I don't I don't say that I definitely don't think that going to US is a prerequisite for something or Will make your life so much easier it depends if I'd started a gaming company I probably wouldn't go to San Francisco it doesn't make sense and In terms of getting funding in Nordic Lifeline is one of our first investors, but most of our other money came from from the US So I can't really talk about fundraising in the Nordics Except that I've helped some other startups raised funding here, and I'm doing some angel investing myself now as well And it's definitely quite a bit harder here It's harder to create that FOMO and that momentum because there's so there's just fewer investors And it's harder to find that one. Yes among a smaller group So how much equity does the team still own after all these rounds? I mean that depends on obviously the valuations and how you structure them We don't disclose the sort of valuations that we take the investment in But there are some sort of general outlines That you can find online how much teams usually own after a seed round or so on So yeah, I don't really want to delve into that did you notice difference between American and Nordic investors? To a certain extent, yes, I don't have a ton of experience with Nordic investors in terms of US investors. I think they See a lot more deals can be a lot more professional especially angel investors It's just the fact of being in San Francisco where there's so much more Happening so much more deal flow that they're usually quicker to move and maybe are willing to take bigger risks on on new products Where to try something coffee and Helsinki? Unfortunately nowhere right now. So we're focused only in the US market now It's really hard to ship it We did ship Internationally in the beginning, but it turns out when you ship brown powder and like tubes a lot of customs get interested so a lot of packages got missing and got stuck somewhere so we Decided not to do it and it was just more of a hassle. How do you define the perfect investor? frankly really The main thing that you get from investors is money So many investors advertised themselves as smart money. Nobody wants to be dumb money But still and that's like what a lot of the top investors would tell you I was just watching Steve Jervitson's talk from slash last year where he said that if any investor tells you like he said that at most investors are sort of your Best cheerleaders, and if they tell you more or they're probably lying or something along those lines So it's good not to be sort of too. I Don't know soft or idealistic about it It's it's mainly money. They can help you with their Rolodex So introductions hiring and in some cases if they have like a deep Knowledge or substance in your field maybe more in terms of like super angels Let's see you started a wearable company and and somebody who's done Misfits before is probably a great angel investor for you But I don't think there's sort of the perfect investor So do we have a product when we entered YC or only a concept? We did we actually apply to YC four times and only got in on the fourth time because they viewed as a Basically the first ever food production company that's got an end But the big big sort of picture We had for Saturdays to become a technology company. So we did have a product We did have a pretty strong growth already and and most of the time YC is Heading to the direction now at least what it seems to me can talk for them, but Looking for teams who already have some traction and have validated that what they're making is Scalable and interesting and some people actually want it What is my favorite book that's taught me most about business? That's a good question I am a big fan of Ben Horowitz's hard thing about hard things. I think it's a it's a must read for any startup founder It's it's Dale Carnegie is what the book about it's a really classic one Basically, it's attacking names like how to make friends and be successful or something like that but it's a it's a really good one and then one of the things one of the looks recently that I've read that I've really liked is is Leonardo Leonardo da Vinci's biography by Walter Isaacson that just came out and highlighting the importance of curiosity and Doing anything and I think it's hugely important for a startup founder to be curious to be learning all the time to be asking questions and Also to be interested in when you want to start up you want to be very focused on what you're doing But you want to be curious about your customers about how they use your product how you can make it better for them And ask a lot of questions and talk to your customers to make your product a lot better Is setting coffee ethical? Yes, we source the coffee directly from the farms with a bursting partner who really know and trust So it is as ethical as coffee gets basically Right, I think we're out of time. Thanks for listening to everyone And I hope you enjoy the rest of your slush if you have more questions, feel free to email me My email is is for as I call a Last name first name at gmail.com. Happy to help. Thanks. And that's it. Thank you so much. Call it. Thank you


The objective of this study was to investigate the effects of varying levels of fish meal, FM, and salt supplementation on the growth performance, feed conversion ratio, and gene expression of two key proteins involved in nutrient transport in European sea bass, dysentrarchus labrax. The results showed that increasing the amount of FM in the diet had a positive impact on growth performance, while salt supplementation increased the expression of the peptid transporter gene, PEPT1, but did not affect the expression of the neutral amino acid transporter gene, SLC6A19. Additionally, the addition of salt to a diet containing a low level of FM improved feed intake, as well as specific growth rate and feed conversion ratio. This article was authored by Simona Ramaldi, Elena Bossi, Sheenan Harpers, and others.