Excellent. Gotcha. Thank you. All right. Tim, are you there? Tim, are you able to talk to you about William? Hey William, was that Tim back there too? Yep, I'm here. Excellent. Thank you. All right. One more minute though. I'll get started three after the hour. Hines, are you there? Yes, I am. Cool. Hey Matt, how's it going? Present. Present. I'm alive. That's good enough for you. All right, three afters. Anybody I miss? I think I might have for everybody. All right, let's go in and get this show on the road. That's unusual. We don't have comments. All right, let's get started. Community time. All right, any community related topics people would like to bring up? Nope. Okay, cool. SDK work. We have not had a meeting, so I don't think there's anything to bring up there. Demo work. Good to see. So, actually, let me pick on somebody. Scott or the other Doug, anything you guys want to mention aside just from us making good progress? I guess, from my perspective, I'm looking for an update from you and Scott. I've parked out time on Friday to do some work on this, so I'm going to spend tomorrow working on that. Okay. Yeah, from my point of view, I was going to spend a good portion tomorrow and this weekend, we're working with the intern on getting the infrastructure for the demo set up so that hopefully by our Monday phone call, we should be in a state where everybody wants to participate and just follow a simple list of instructions to figure out what they actually need to code up. We do have, we've made some really good progress on the demo flow itself and what the events are going to look like flowing back and forth and so I guess that hopefully we should be ready to go and go ahead down on Monday. Okay. Let's see. Cook on EU planning. Nothing really big here to mention other than I did put together some template where I put together some Google Docs for the template for the slides. I know no one's had any time to actually work on the slides themselves, but if you are working on either the intro and deep dive or in the serverless working group session, the templates are there with the links here on the agenda. It's just basically the intro title page is more than anything else. So Kathy and I, Kathy, you and I need to work on the Practitioner Summit slide deck as well. I think I did put the slide deck for that. The template is out there as well. So anybody who wants to review our work for any of those four different slide decks here in the links, you can take a look at it as we start making progress, but as of right now, they should be basically blank. Let's see what else. Okay. Nothing about Cook on China, I don't believe since last time. I still have not started the slide deck for our yearly review. That's on May 7. I did ask for some time from the TOC, I believe on next week's phone call to get some clarity on what they meant by three independent end users. So hopefully that will help us decide whether we want to or can go forward with possibly moving to incubator status out of sandbox if we want to. But I figure we need to at least understand what the requirements are before we actually have that discussion. So hopefully we'll get that next week. All right, before we jump into PRs, any other high level topics people would like to bring up that I may have forgotten about. All right, cool. Moving forward then, Scott, you're up first with a hopefully relatively easy one. All right, would you like to talk to this one? I was just finding it difficult to search the text at master. I noticed there's some conflicting data that's happening. So I changed the version to 0.3 width so that it's clear that the version at master is the future version, not a back ported thing that's supported in P2. And we did talk about this briefly last week. We decided that rather than just sticking with just 0.3, we put something at the end to make it perfectly clear that it's just a work in progress. Scott made those changes. All right, any questions on this one seems fairly straightforward. Any objection to approving this one? All right. Thank you guys very much. Thank you, Scott, for that. I know there's been actually a confusion point for some people in the past. All right, next one. This one has been out there for a little while. Now, Kathy, this one, we made some edits based upon some of your suggestions in particular, I believe.  And I believe, what was the gentleman's name? Who owns this one? Is it John or Jay? You know, Jay Roper. Left, added the text, but then left out that part that you were concerned about. So I'm hoping that this text right here addresses your concern without introducing the stuff that you're worried about. Yes, is this what you wrote? I believe so, yes. Okay, yeah. Thank you, Scott. Yeah. So I know that everybody's been paying attention to this. So let me give you guys just a second to, let me just see this. Yeah, the main parts right here are these two sections. I'll give you guys just a minute to look this over. But I think we have talked about this in the past and we're almost ready to go. And then Kathy had some last minute questions and concerns. And this is the paragraph that tried to address them for concerns more than anything else. I'll give you guys just a second to read that and come back up to speed. Okay, so just a reminder, this is just an extension. It's not part of the court. It's not being proposed for the core spec. Are there any questions on this or concerns? I think this is getting a great direction, but would still prefer some more examples or where there's some below. I don't believe there are examples as of right now. Yes, there were some pretty great examples discussed two weeks ago for this. Now that I said that I don't actually remember them anymore. Yeah, I think Clemens, I think Clemens had some really good examples. He was going to write up. Am I correct in assuming though that we could do those as a follow on PR? Oh, sure. And the reason I'm pushing a little is one, this one's been out there for a while and I feel a little guilty that we kept them on hold. Even though it was good discussions that had to happen, but I know that this is also a blocker for the Kafka transport. I know there's some people are very anxious to get that one in there. Well, does this really solve the Kafka transport issue? Because even with Kafka, you have no idea what partition it's going to put key data in. I'm not an expert in that space, but I believe they wanted to leverage this extension in their transport definition. This is literally the same unless you are writing your custom producer that manually sets the partition. This is literally the thing you give to Kafka to do the partitioning. So yeah, this solves the problem. But Kafka does not automatically use a partition. It determines the partition based on a hash of certain data and it automatically in the client will put it into the correct Kafka partition. Yes. Sorry, go on. No, no, sorry. Yeah, yeah, sure. So basically in Kafka, the client decides the partition, but it's unless you're doing something really weird. You use murmur to hashing on the key of the message and the cloud event spec has no place for the key of the message, which is a important primitive in Kafka. So you have the key and the message and the hash is always on the whole key, the binary data of the key. So this is the binary data that you would use for the key in Kafka. And this would decide the partition based on the hash of this key. Is that answer your question? No, but I don't think we need to go into this early, but again, the cash is created by Kafka under the covers. So, you know, if you send a cloud events and you basically pass that to Kafka, Kafka would have to still manually put a key into the data. So that's what they're talking about. That's fine. It's a separate key, but it wouldn't be the key, the key hashing that Kafka uses that you put it in a partition. So you could actually use any key doesn't have to be specifically a partition key. I guess I'm saying that's just the name of the field or don't understand the problem. Well, I think it's redundant because if I was doing a Kafka binding, which doesn't exist yet, I would use something like a correlation ID or probably a correlation ID in the cloud events message. And then when I pushed that into a Kafka binding, I would use the correlation ID as the Kafka key, which would automatically get hashed and put into the correct partition. So I could. So this is just a redundant version of perhaps another key like correlation ID that already exists. Well, yes and no, what you're talking about is a semantic ID or key that would be used for partitioning. But the problem is that partitioning is a process defined. It's process defined. So you might have different hops that need to partition based on different correlation correlation IDs. Correlation ID is a very generic field name. It doesn't really imply anything. You could have many of those for an event. The point of the partition key extension here as I've understood it is to create the canonical plays for that key. So if you knew that you wanted to use correlation ID X as your Kafka key, you would put that here for your hop. But when you pass that event forward, some other consumer or some other process might want to partition it differently based on another correlation ID. Then they would modify this field as the extension spec says for their use case. That's the, it is redundant, but it's redundant intentionally because it makes it unambiguous what you actually want to be the partition key. Otherwise the binding actually can't know or it would need to be a specific parameter of the binding or something. I don't even know, but these was all of those options were discussed beforehand. For example, Clemens had that idea that you would use a path to get the Kafka message key from the cloud event. But instead it was decided to use something that already exists. So that is extensions and attributes there. And since we don't have a decision that extension field should be immutable, this seemed like the proper way to do partition key because you, it's not set in stone. You want to change it between hops, most likely. Okay, Timmy. But a correlation should be immutable, right? It's a correlation. No, it should not. So Clemens had a great example here where if you take in a huge amount of messages and then you partition them and you give each partition to a downstream consumer. And that downstream consumer then again needs to partition it. If your partition key is immutable, the downstream consumer actually cannot partition it because they already were in the same partition, which means the key hash to the same bucket. So the downstream consumer actually has no way of partitioning their set of data, which they read from one partition upstream, because their keys are all hashed to the same bucket. So that is why it's not possible in something like Kafka to have an immutable key if you actually want to create complex pipelines. Well, that's the point though. In Kafka, you would use a stream processor. It would be an immutable key because everything you put into Kafka is immutable once it's into Kafka. It's immutable. It's not immutable between you and the next hop. They can modify their message when they put it into Kafka again after they've processed it. The point here is you wouldn't modify this like in place. You would process your stuff, put it into Kafka. The next consumer will process their stuff and their results would have a different partition key, which would then repartition the resulting data. There's just simply no way an immutable key can work for the whole pipeline. Well, it can because when I do my stream processor, it goes to another topic. That topic will have different partitions and it would then use that same partition key to partition it again in that second topic. If you use the same key and you have, say, same partitions in both topics, your second topic will have the exact same partitioning as your first one. The murmur to hashing is intentionally deterministic. What you're saying doesn't actually repartition the data. It just puts it again in a different topic in the same partitions. I think the confusing repartitioning of Kafka, which is adding partitions to the same topic versus stream processing against the immutable messages in one topic. I think we're going off on a tangent. We need to have a side discussion. Hold on just a sec. This is a problem we have all the time in event processing. When you want to send events somewhere and they get very high volume, you have to use sharding because that's the only known way to have arbitrary high volumes. The conventional technique we use is not to specify our partition key literally, but to specify a JSON path or equivalent saying, for each event, here's how you pull out the partition key. That seems to work really well in practice. I know in our messaging products, we do the partition keys when I need to partition, completely transparent to the payloads. That works fine as well.  This is very Kafka-ish. I'm saying with Kafka, it would be redundant. It is immutable if you are using an example of repartitioning that is a stream processing in Kafka, which, again, if you want to use a separate key, it would be like the equivalent of changing a correlation ID, which you probably would not be allowed to do as far as a lot of these business apps. Without this extension, how would you specify that? Would you specify that key? You say different parameter. How would you define for the Kafka binding your key? Well, when you do the binding in Kafka, you would be able to choose one of the other keys that are already there, which would probably be the correlation ID, because you want to end correlation. As I said, that was an idea by Clemens, which was disregarded in favor of this extension, which is the same thing in a different form. You would set whatever your wanted correlation ID. If you never want to change it, that's fine. Or if you want to change it as you just said, that's fine as well. But this extension is where you would set that key. I don't understand the problem. It's not a problem. You can add. I'm just saying it's redundant, and you want to keep adding redundant fields, especially if it's targeted towards only Kafka. And I believe it can be done without adding this field in Kafka itself as well. So I'm just trying to cut back adding extensions that may be redundant. Or redundant for only one binding. So I want to make sure I understand what you say redundant to me. Redundant because this data someplace else, in particular. In a correlation ID or a combination of correlation ID and stream ID. And because there is no current Kafka binding, it's kind of, you know, you're adding things for another potential spec that doesn't exist, which is the Kafka binding. Right. But I, right. But I think if I remember correctly, I believe that, oh, that, that, that spec does exist in the sense that it's a PR. And I think they, rather than wanting to create their own extension, just for them, they thought this was, this was a generic enough thing that maybe it should be a standalone extension. Indeed. This is a blocker for the Kafka spec. So I don't really understand your argument. Well, again, depending on how you spec out, even if I did a, if I wrote the Kafka binding, since I could use the keys as full objects, rather than single strings or fields, I would actually do the binding where I would allow them to specify attributes in the header. Or it could be attributes even right from the payload that I would create before I actually wrote the record to Kafka. So adding a separate field for partition I think is redundant. There's enough in the current spec to be able to do all the key stuff you need for Kafka. For partition. There's no generic way of specifying what that data is though. That's what this extension is trying to solve. Hold on a sec. What you want to do is for, have specific ways in each binding that we use a partitioning key to specify it from inside the event if I understand correctly. Yeah. So Christoph has his hand up and let him jump in every second. Yeah. So what I gathered from the discussion that the other people had was that for them to be able to put it into a Kafka partition, they have to have a way of letting an event producer decide in which partition it should go. So this is the way for the event producer to tell whatever Kafka middle where there is, how it should be partitioned. I'm not sure if like, because the Kafka binding should work for all cloud events, also for cloud events that don't have a partition key. So they probably have to have a fallback in the end. I don't know what that will look like. What I think what we should get at is that this is an optional thing that an event producer can add. So that then a Kafka or another messaging protocol that wants to partition can work with. We should kind of see that it is an optional thing. Yeah. It's only optional. It is just an extension. So Heinz, I'm trying to figure out. Go ahead, Scott. Yeah. I don't think you want the producer to choose the partition key because they're going to choose a bad value. You want the middleware to be able to specify what the key is. And I don't think the consumer really cares at the end because it shouldn't need to know where the event came from, from which partition. Is that right or is that wrong? It depends on the use case. I made the same point actually because I'm like, I write really, if you write a software service, then you don't really know what your consumers will, what if you write an event producer in your own ecosystem, then it's very likely that you have the knowledge of your consumers. So again, I think it's optional. So if it's a way for them to move forward with the Kafka binding, then that's kind of okay for me. But they can just use this binding or they can use this key as an extension and not have it be in the spec because it's part of Kafka. The Kafka acceptance thing should know that this extension exists and the producer...  Yeah, I got zoomed. You want to finish your sentence? I don't think that the original cloud event producer needs to care about what partition key is going to be sent downstream. It seems to be an individual hop. Doug highlighted the part of the text. He's highlighting it again, which exactly tries to convey that message. I don't understand why you would not spec this as an extension and why would you leave it to the individual transports because if you have a Kinesis transport and a Kafka transport, they would work exactly the same way with this extension. I don't see a reason why you would leave it to the individual bindings to define an unspecced extension when you can just do it generically. But that's the point. The binding in Kafka, if I had the binding, I wouldn't want the cloud event to force me to use an extension, which is only a single string because I may want to define in that binding that I'm using parts of the payload and maybe other header properties to configure an object for the key by telling them they can only use this one optional value as the string. I think it's going to be the service when they have a Kafka binding to limit them on what they can actually use for the Kafka key. Are you saying that as a producer or consumer? It's always for the producer because the consumer is going to bind to all the partitions and pull it out or you will use a stream processor to bind to all the partitions, pull it out and write it to another topic that then just has those key values. Right, so my assumption, I think Topini covered my wrong here, but my assumption was that the producer would use whatever values they need to to decide what the purchasing key is going to be and then they would stick it into this field so that the consumer could then use it and wouldn't have to do, in essence, the exact same logic that the producer just did. If you're building an in-house system, probably yes, but not necessarily. The producer might not even define this key at all if they don't know it's going into Kafka and then some middle word that's actually putting it into Kafka will define it because they know how it should be partitioned. I now understand how it's what you're going after. You're going after the fact that Kafka already has a key that is used. The problem is cloud events are singular objects. They are not split as a key and as a message as in Kafka. So you need to somehow define that key. I don't believe it's a disservice to generalize how that key is defined. You can still put any data you want in here. You can encode your objects, your headers, whatever you want here. It's still binary data for Kafka. Kafka handles everything as a binary data. So this is just a way to set the key in a cloud event which doesn't naturally have a separate key to partition on. Yeah, exactly. And this is where the binding in Kafka. I would then define that of how I'm going to create the key. I don't want to have it limited to an optional field. Right? No, I don't understand or I don't grasp the difference you're after. I just... Well, I will change and try a different use case. If you do the use case of building, for example, a Kafka connector. So let's say I've done a binding of... Let's say I'm using just some other messaging middleware. I've written a Kafka connector and I want to push that cloud event message as part of routing into Kafka for some processing. In that connector, I determine what the key is going to be from that third-party messaging where I do that part of the connector, which would be the equivalent in the cloud event in the actual binding of the Kafka binding against the spec. So that would be against data that I've already received, either header data. It could be payload data. And I would then determine how I'm going to partition the keys for writing to Kafka, which will automatically put it into the correct partition. There's no real... You're limiting yourself with an optional field to build that binding. I think we just simply disagree with them because I don't think this limits you in any way. You have to encode your data as a string, which, okay, yeah, not nice if you use the normal Kafka clients, but it's in the name of generalization. I don't think I will be able to convince you that you don't lose something here if you do think you lose something here, because to me it's just two different ways of defining the key. It will still be this key in Kafka. It will be partitioned based on this key. Kafka will automatically choose the partition based on this key. It's just encoded as a string instead of as any binary data you want. Actually, it is any binary data you want as it's a string. I don't grasp the huge difference you're after here. I'm just saying it has two issues. One, it's either redundant because just like with a connector, for example, which would be similar to building the binding, protocol binding, you would be using data that already exists in the cloud events, either in the payload or as part of the header to determine the key, the same thing you do when you do a connector into Kafka. No other messaging has a concept of the key when you're writing a source connector for Kafka. Therefore, you do the exact same thing. You look at the payload and header data that you've just received and you determine then how I'm going to create the key, which is generally an object. It's not one field. It's usually a combination of things to build the object as a key, which I then pass to Kafka, which will automatically then figure out the hash and put it into the correct partition automatically. So it either is going to be restrictive if you expect them to use it or it's redundant because you're going to use other data anyway, just like with a connector. So Scott, do you have your hand up? Yeah, my question is how does the producer use Kafka or whatever if they don't understand that they're going to be sending to Kafka? If the original message has no partition key, how does that get injected into Kafka? That's the same as you would use with a Kafka connector. You would then look at that payload and you would look at header data and determine what are unique attributes that I want to group all the data to make sure it's all ordered against that group's data. And it's either a single field like a correlation ID or it's a combination of payload and header data where I would create an object and when I actually now create the Kafka records to write it to Kafka, I would add the payload data that would probably be right from the full cloud events payload and header, as well as now the key data that I generated to create the key when I wrote the record. So that's exactly what you do with a Kafka connector as well in and out of any other third-party system. So it sounds like the payload doesn't get modified on the injection? No. No, there's no modification of the payload whatsoever. You're just adding a key because again Kafka are just name value pairs where the key is the name and the value is the payload. So Topini, your hand was going up there for a minute. Did you want to say something? Yes. I'm sorry to keep repeating myself but there is no difference between you specifying a group of attributes as an object and you specifying a group of attributes encoded into a string because they are both binary data that Kafka will use for the hash. There is no technical difference between those two things. Between you choosing in a Kafka connector a group of attributes and encoding them as an object into the key and you encoding those same attributes into this field as a string. Kafka will not care. It handles it all as binary data. What I do understand from your objections is the fact that this will indeed duplicate the key into the message if I understand correctly how this extension work. Unfortunate in my opinion. Some people gave examples where that would be useful because on the consumer side you wouldn't get the key from Kafka. You would only get the cloud events and this then would specify what was used as the partition key so you could even reuse it if you want. I know. I simply disagree with your problems with this. Sorry. It's been a good discussion even though most of it's over my head but I'm trying to figure out Heinz. Are you suggesting that we should not adopt this or just that it seems like it's unnecessary because it's duplicate information? I believe it's unnecessary information because everything you send to Kafka either through a stream processor, a connector because really what you're doing is some kind of integration which is really what we're discussing. The integration point either the stream processor, the connector or in this case which would be the Kafka binding which does not exist yet. It does not assume that you have created a key for Kafka inside of it. Do you do it before you pass it to the Kafka environment or after? I'm saying that you would always do this after just like when you wrote a connector. You're not going to tell the upstream third party system to say I need you to calculate this partition key for me so that when I pass it to Kafka it can use that partition key. You would do that in the binding layer for all the cloud event data. Now I need to key this data because I need to have it guaranteed to be in order process in Kafka. I would then calculate the key when I write that record from that third party system into Kafka. So why would you want to calculate a Kafka key before you send it, put it in cloud events? It is so tightly coupled and duplicating what you're going to do in the other side anyway. Okay, Kristoff, your hand went up first. I think we're getting to actually the point that the offers of this try to make and I think their point is that I want to write a binding that is just standard code and that you don't modify at all. So if you... And it works like generically across events that I have never seen. So in which in the case that Heinz suggests means I always have to go in, I have to understand I get events of this shape, blah, blah, blah. I have to extract my key and so on. What they want to do is they want to write something that is the same for any type of event and then that changes the way I think. Does it make sense what I'm trying to say? No, totally. Again, do I want to create the key before I put it into the event to make sure it works and make it easier to write a Kafka binding or do I keep it completely separate where it has no knowledge that Kafka is going to be involved in the cloud event and then have to have some kind of configuration or some kind of interface to allow this to work in a Kafka binding? Yeah, exactly. So I try to make exactly this... Sorry, go ahead. I try to make exactly the same point to the offers that there will definitely be events where they cannot assume that the producer made or added a partition key and then he will always have to at least have some fallback. But I think... Yeah, I think my personal opinion is that we should look at this together with the binding that they propose and then if we as a group think it doesn't make sense to have like a generic binding, we should always assume that a binding when Kafka comes with a configuration that would also be something but it needs to be discussed in the context of the proposed Kafka binding. I agree. So Tapini, your hands up. I disagree. Those two things are not exclusive. This extension specifically states that you can redefine the partition key. So that is the point where you define it after you get the event hines. It's not producer only... only producer defined. This says specifically that you can change it. In cases where the cloud event is delivered to an event consumer via multiple hops it is possible that the value of this attribute might change. That is the specific part that says you are not tied to the partition key set by the producer. That's one problem that came up. Christoph, for your thing, if one does not exist I would assume most producer wouldn't set this key. That's fine. If you don't have a key it will go to a random partition in round-dropping fashion. If you know you're going to put your messages into Kafka this is the point where you would say where you would define that key how you want them to be ordered. I don't actually... I understand the concerns. I think it's a problem with the wording that this doesn't convey how it should be used. I think Scott has a good point in the chat that maybe this shouldn't be top-level extension but something else. We just don't have that something else which is why I think this was defined as an extension so the Kafka binding could get moving because we also didn't want to do a Kafka binding specific way of specifying the key. That's what Clemens actually suggested weeks ago but somehow I wasn't part of that conversation. That was disregarded. I don't remember why. I think we need to wrap this one up at least for this phone call. So, Heinz, can I get you to take an action item here and put down your concerns into a comment into this PR because it seems very odd to me that the authors of the Kafka spec feel like they're blocked by not having this and so the fact that they consider it is sort of required bit of information in order to make forward progress says that something is seriously needs to be discussed. It's the fact that you need the key for the message and there's simply no way as envisioned now to set that key for the Kafka message to ensure your ordering. They didn't want to do a binding specific thing. Is the key needed for the consumer? No, it's needed to actually put that message into the correct partition in Kafka so when you are putting it into Kafka you need to know the key. There's currently no way to set that key without the Kafka binding creating its own special way of doing it and I don't think that's the correct way to do it because this is not a Kafka specific thing so that is the major use case we're talking about now. Kinesis is a good second example. They have the same model. I think the quality of this debate would be greatly improved by having some concrete examples to look at. Yeah, that's what I would prefer before I start making comments because when we throw out things like well it's for routing, well even in Kafka if you're routing it isn't moodle to put it into the first topic. Routing is all done in Kafka using stream processors and you can create whatever key you want it has nothing to do with the original publisher as the original cloud event. Okay, so I think I'm hearing a couple of things. One is some examples, I think Scott you call the use cases that's fine. We can ask for those but Kines, can you also add some comments to the PR itself explaining your your concerns? I'd want to see if we can wrap up this conversation in relatively short order over the next week or two. As long as the next week unfortunately I'm gone the whole week so if you don't mind till the week after then yeah that's no problem. Well, can you at least add your comments today to at least get the conversation going? Well considering on holidays today and I've missed the last two so I think I better come in just do all.  That I understand, okay. Well, you can add comments. Kristoffer, Tapini do you guys understand Heinz's concerns well enough to maybe put a comment to at least get some of the conversations going in the meantime? Well, I do not want to describe Heinz's concerns because I think I have some kind of grasp of them but I don't understand specifics or I don't understand the specific concerns so I do not want to speak for him. Which I appreciate. But I was just going to say it's very simple. I believe it's redundant and I believe like every other way of injecting published data from third party from anything into Kafka the key is always generated at the binding or the connector or at the stream level. It is not done necessarily at the external source which is the architecture for things like Kafka connectors which is a standard way to get the data into that. Agreed, I think you simply this extension does not define it as something defined by an external source. It specifically says you can do that at the point where you are putting into Kafka I think that's where we just disagree on how that should be done. Right, okay so I'm going to call time here because I think Kristoff you had the exact same thought I did I just put into the meeting minutes. What I'm going to do here is two things. One is ask the authors to give some concrete examples and use cases for this and two ask them to watch the recording of this and then they can comment on that back in the PR itself because I think I think the author of this is technically in Australia so it's going to be really difficult for him to join this phone call I believe. So let's see if we can make progress through those two avenues, okay. Excellent discussion I think very lively which is unusual for our phone calls so that was good. Okay so let's talk about Alan's PR here. So overall I don't believe Alan's on the call right now Alan's PR here once it loads is he wants to add some text to basically clarify that source plus ID uniquely identifies any event and in particular you can use that for dedupe or something like that if necessary. I believe on last week's call we talked about this a little and in particular Scott I know you weren't there but we tried to bring up the idea of including type as part of the as part of the uniqueness aspect to it and there wasn't a whole lot of support for including type in there but I wanted to get your I want to give you the opportunity to speak to that if you wanted to without before we just decided without you on the call. So did you want to talk to that because I know you were advocate for it. Yeah it really does need type because ID is something that is that can come from the originator of the event the producer the source is coming from the producer but type comes from the adapter so there's no way to understand that the particular event comes from a particular adapter if it doesn't have the type because type gets to be accustomed to the adapter not the producer I think you may need to elaborate a little what you mean by adapter because that sounds like an implantation detail. If a particular producer is not a cloud event and it tells you a bunch of data so like we had this case of a database commit ID right online 250 you can adapt that into a cloud event and the source and the ID will be exactly the same for two different implementations of an adapter to a cloud event but the type should be different because the type comes from the adapters implementation so the only way you know that that event is a dedu is if you also include the adapters ID which is the type.  Can you what I don't understand is why would you have the same event come into your system with two different adapters. I have the prod adapter and the beta adapter potentially or I have two different implementations of a similar adapter because I'm evaluating. So my hands up next. So it seems to me that Scott the adapter is going to blindly take some ID that it got from the system that actually produced the event or generated the event. It's that adapter job to manipulate that ID in some way before it uses it as a cloud event ID and if that means adding some unique thing to it some additional unique thing to it like maybe the type maybe some other identifier and concatenate it whatever it seems like it's that adapter's job to make the cloud event ID unique if it was trying to use some previous field that isn't unique unto itself then it was making a bad choice to begin with. Does that make any sense? So do we lose Scott? No I'm just processing. Okay yeah because my point is that just because you want to use an ID that was given to you doesn't mean you maybe can use that ID because it may not be necessarily unique but this field has to be unique so you need to make it unique as that adapter. But the ID is unique for that individual producer so it's still conformant to the spec but you can still have two producers that are producing the exact same event according to this definition of unique and you won't be able to understand if it's from producer A or producer B because their upstream source of truth is giving them the same data. My understanding drifted because when I think of source I think of source as uniquely identifying a producer. Right. In that case, both of these two adapters would have unique IDs for different sources. They are not the source of the event. They are just an adapter. They're taking a non cloud event payload and turning it into a cloud event payload. That's my question about my understanding. I'm trying to crack what you said there, Eric. My understanding is that source is effectively a unique ID of the producer of the event rather than some data like a database name or something like that that could then be used as the source or by multiple producers. Source is just a URI of the originating entity that's making the event. So now actually we have to add subject. So source is the generic potentially bucket name. Source is that the bucket object would be the subject. Scott, you went on mute again. Zoom keeps doing something funny. Okay, try again. Well, regardless, I think because we now added subjects, we have to add subject here too. So it becomes a four pole of source subject ID and type. That's how you know it's unique. I guess I'm still confused though, Scott. It seems to me that you're trying to assume that the ID that's given to this adapter it can't be changed in some way to be made unique unto itself and that this ID has some semantic meaning outside of just providing uniqueness from a cloud event perspective. Am I correct in that assumption? How would you know as a consumer of that event how to unmangle the ID back to the database commit ID if it goes to the producer? That's my point. He shouldn't. This ID is not meant to be anything other than uniquely identified this cloud event from other cloud events. It's not supposed to have a semantic meaning like a database commit ID. You can use that ID if that ID happens to be globally unique but it's not meant to convey oh, consumer use this field for the commit ID because that's not what it's there for. There's some other field for that. I still think that example should be removed because it causes so much confusion. We tried to remove it in some other PR. Yes. Because it implies there's additional semantics aside from just cloud event uniqueness. So if you do that then you don't know how to deduce the data unless you also look at the payload and now you can't do any you don't understand how to deliver once events. Well, I don't think that's true. It depends on whether you want to dedupe from a cloud event perspective or dedupe from some sort of semantic meaning of the event itself perspective from a cloud event perspective of resending the exact same cloud event I think you can do it with this ID. But if you want to have some semantic smarts and somehow do deduping from a data perspective that's outside the scope for us. Does that make any sense, Scott? Yeah, I just don't really agree with that sentiment. I think there is something interesting here but we also need additional data to understand if the event is deduced or not. Well, the problem I see though is if you head down the path where I think you're headed where there's additional semantic meaning behind this ID how the heck are we ever going to define what that semantic meaning is? Because it's going to mean different things to different people. Right? The idea of the cloud event is we get to choose what this ID means. But this meaning is going to change depending on the use case. Yeah, yeah, that's right. But I think if you force the ID to be modified by adapters that turn it into a cloud event so that it can play in other ecosystems, you lose the original intent of the event. But I guess I just don't understand.  But everybody perfectly understands what this thing means and how it's meant to be used. This ID what you're suggesting is it can have multiple purposes not just uniquely identify cloud events and stream of cloud events to convey some other semantic meaning that's defined at the application level. And I don't see how you can guarantee that those two meanings won't conflict for all time. Well then we should change the cloud event attribute from ID to transaction ID or something because if it's just the GWID that we give it as an ingestion key then I'm not sure what its purpose is anymore. I think that that is its purpose basically is simply provide a unique ID for this cloud event so you can differentiate it from all of the cloud events. But then you're sending multiple cloud events that de-dupe on the transport but are the exact same content. You're sending the same event multiple times because they have different IDs for cloud event ID but they're exactly the same content for the payload. And now you've pushed the exercise of de-dupe to the consumer instead of the transport. Why would they have the same content? Because they just replayed all the database commits. But I think if you're asking cloud events to de-dupe that I think you're asking it to do too much because now it has to understand the semantics of the application. I don't really agree with that. I think this is what it's for. Okay. I don't know this one. Another one needs to take offline. Scott, can you do me a favor? In that document that we have where is it? In this document right here can you add some comments in there explaining exactly what your definition of the cloud event ID would you think the definition of cloud event ID should be? I already did. Okay. I didn't see that. De-dupe. Speedy today. So where is your exact definition you'd like it to be? We can talk offline. It's in the climate. Okay. We'll talk online. We'll try to continue this through this document. I think that's probably the biggest difference of opinion is what is the ID meant to be used and what is its semantic definition. We need to get some clarity on what different people want it to be. Yeah. Only three minutes left. I don't think we have time to jump into another issue. Especially since the next one is the big one about the code issue. What I will say is this though. We have technically a phone call scheduled right after this for the Kupkan EU session. It may be a very short call but for those of you guys who are planning on doing one of the three different or four different sessions at Kupkan EU please join that call as we can get some syncing going there. In terms of people on the call I believe I have everybody except Mehmet. Are you there? Mehmet? Okay. Did I miss anybody else on the call relative to attendance? Yeah, this is Maroon. Hi, this is Mehmet. Hey Mehmet. I got you. And Maroon, I got you. Cool. Anybody else? Okay. Cool. In that case, thank you guys very much. And we'll talk again next week. Oh wait. Javier, are you there? Hi. Excellent. Okay. Just made it then. Better late than never. Okay. Thank you guys. We'll talk next week.  Hines left. He's on vacation. I forgot to mention a few problems with defining it in binding and I wrote them in the chat but I guess I have to transfer those to the PR now. Probably. I'll be really great because I want Mr. I don't get to be lazy. Actually, I'm trying to copy the chat because I missed most of the conversation. So hold on a minute. Let's see if I can do this. It's funny how such a simple thing can be so complicated. It's actually a binary field within Kafka. It's just binary data that is used to partition something. It's funny how that can be so hard. Sometimes it's simple things aren't quite so simple. All right. Well, it's not time yet. Let's give another minute or so. I'll get it organized here. Doug, I delete the private messages. There's a phone number there and that can be considered private.  Sorry. Private. Private. Where are the other private ones? Is that it? Oh, thank you. Was there another one in there? Actually, I guess I could just search for the word private. I want to also point out that you're still recording and that phone number will be visible in the recording. Damn. I will talk to Solace if he can get that fixed. Let me stop recording for a second or at least stop sharing. Where was that phone number? I didn't see that. Was it in the beginning? Actually, no, that's okay because that actually shows up in the zoom anyway. It's not like he was giving me his phone number to call him or anything. It just shows up in the zoom and I think that might show up in the recording by default. What is it? It might. I don't know. Well, let me put it this way. I actually said that phone number. I believe at the very beginning of the phone call. Asking who it was. Either way, we're screwed. So. Anyway. Whoops, wrong one. Let's try this again. Okay. Now that I've completely messed everything up, let's see. Uh-oh. What do I do now? No. I'm trying to figure out how I get... I'm on a different computer than usual so I'm figuring out how to get all of these comments I met in the chat to the PR on another computer. Well, you can... They're in the Google Doc now. I did put them there. Oh, great. Thank you. Yeah, that's right. They were complaining that I copy and pasted into the end of the agenda. Yeah. Okay. Hold on a minute. Thank you and sorry for using up all the time arguing about one issue. No, it's a good discussion. It's just, you know, it's unfortunate because I know everybody's really busy and this is the kind of discussion that you'd like to have through the PR and stuff. But of course, that's not necessarily the best way to have a conversation and we tried to have phone calls, but then the time's just gone away. This is the kind of way it has to play out sometimes, but it's okay. We'll eventually get there. Yeah, sure. Let's see. Thank you. Bye. Okay. Bye. All right. So let's see where are we. Okay. So Dan said he's not going to be able to make it. Boom. Let's see. So Scott, you're still on the call. Good. Okay. So... Kind of been a bad spot, though. There was a fire alarm and I'm in a cafe with like 3,000 other people. So, slightly noisy. Actually, it doesn't sound that bad to be honest. I don't hear too much background noise. That's not too bad. Okay. I don't actually think we have a whole lot to talk about because I don't think anybody's gone through the process of actually starting to fill out the charts. So, but I did want to ask a couple of questions. So if Scott... I'm sorry. If Dan can't make it, is there somebody else who would like to fill his spot? I believe he was going to be mainly talking about the introduction stuff. Who we are, scope of the spec and stuff like that. I mean, if we don't have any volunteers, I'd be happy to do it, but I want to think of other people a chance if they really want to because I've already done this. I think one or two different times already. So, do we have any volunteers to fill Dan's spot? Okay. If not, I'll sign up for that one. I don't mind doing it. So then, Scott, I'll take care of the intro stuff and then you can leave it on with the more advanced, cooler stuff like the SDKs and everything else. And then if we have time, the demo and stuff like that. Sound good, Scott? Sounds great. Okay. Perfect. Okay. The deep dive session. Let's see. That is Vlad and Clemens. I believe... Comments and concerns and questions. Okay. Go for it. Hello. Okay. I'm going to start the deployment pipeline with exceptions. But that is very, very closely... It's basically messaging that eventing. That's what I've been looking in the last week, or last two weeks. Time. And I'm not sure where to go from here. Like it could be mostly eventing to... In my initial plan overview idea, I had a UI that would just have a list of commits or versions you want to deploy and send the cloud event to SNS, SQS, whatever. And then that message would be parsed. But it's kind of messaging. I'm imagining I could easily tie this up to GitHub events to do everything on a commit or per build basis. But that feels like it's going to be a bit too long. So I don't know exactly where to go from here. But again, I haven't spent that much time on it. I times wanted this weekend for this. So... Any pointers? Any preferences? Anybody have any comments on that? To give some more background if it helps. The idea is that I'm working with a client right now who has an app that is very much even driven and scaling and all that. And it would be an absolute perfect use case for serverless. But right now they're doing containers and that works. They're also not being a startup that's only now starting to mature. There aren't a lot of solter best practices to put it nicer. Like no feature flagging, no observability, no AB testing, no all of that. And the way I've seen serverless use is most of the use cases fall into buckets. The first one being new startups, they do serverless because they want to optimize their cost. The second one is companies that are bigger and start playing with serverless to learn more to experiment and usually through internal projects like CI CD pipelines. And the plan was to they're significantly starting to work into automation and automated deploys and proper continuous deployment and stuff like that. I started working on it. I had to send tiny messages between different lambda functions or stuff like that. And we use the honeycomb for tracing and for eventing observability and all that. And I basically started designing a JSON that was heavily resembling cloud events. Like, okay, cloud events. It's boring. If you have to send something over the wire, you can use it. That was the use case and where the idea came from. But it's still kind of messaging. So I don't know. I just want to make sure, right? What's the name of the company you're working with on that? Oh, it's okay. It's a media company. They're doing video transcos in the cloud. Instead of a movie taking a couple hours to be transcode, the format it takes a couple minutes. All right. I don't know. The only thing I was going to say was we're going to work kind of this weekend anyway. Would it make sense for you to write up what you were thinking in more detail? That way people can read it offline and comment on that. Yeah, that was the plan. Yeah, that way Clemens in particular could take a look at it. Yeah. And how long should this take? What's the time slot for this? Well, we have 35 minutes. Okay, so I might be 50-50 between me and Clemens. I would assume so. Yeah, maybe we have 15 minutes each with 5 minutes for questions kind of a thing. I would think. Okay, so 15 minutes. Okay. Okay. And you're all fine with me saying, hey, cloud events are here. They're boring. Use them everywhere. I don't want to have cloud events to be the focus. I want it to be that you need to get data from a point to another. You might as well use cloud events because it's supported, it's growing, it's being used but it's starting to be native to different stacks like how Microsoft has direct cloud event integration. Is there a way for you to position it as cloud events either made your life a little bit easier or just makes life simpler at some point? Okay. Yeah, definitely. Versioning was the main thing. As soon as I had to do tracing, I had to do HTTP header, deserializing and serializing and all of that and that's already done by cloud events and by the cloud events SDKs and I would have just cobbled badly created JSON with some version pack and it would have been a lot of internal effort when I can just use cloud events. Right. That's an important thing. It's here, user.  I mean, that's what they talk about from containers too, right, boring infrastructure. So, yeah. Okay. I'm open to many other concerns or ideas or suggestions. Yeah, I would recommend writing it down so that people like Clements could take a look at it because since you're going to be talking with him, you don't want to have him basically shoot down everything you just said because he's going to talk about this ain't doing great. Yeah. Yeah. Okay. Okay, that sounds good. I'll talk to you later. Okay. Okay. Okay. Create some diagrams and design doc this weekend. I tried to do this for this week but I couldn't squeeze it in. Sorry. Okay, that's fine. Okay, anything else people want to bring up relative to the deep dive session? One thing we do need to figure out is where we actually do the demo because we have it both as question marks in the intro and deep dive. So, at some point we need to figure out which session we'll actually talk about it or do the demo there. If you think 15 minutes is going to be pushing it for you Vlad and I know Clements can easily fill up 15 minutes, we may want to put that into the intro session then. So, Scott, keep that in mind as we go forward because I have to keep my stuff really, really short. If we take the demo and assume the demo is going to be five minutes kind of a thing then the rest of the time can be used for your stuff, Scott. Anyway, something to think about as we go forward. Yeah, I'm thinking of having a super short demo a couple minutes going through it and then going into how it's implemented and stuff. So, I'd rather have the demo in not in the deep dive so more people see it and in the deep dive I would assume like previous knowledge and go directly hi, this is CloudEvent, this is the extension you're assuming people already know what's the extension or what CloudEvent is as not to repeat all that. Yeah, I think that makes a lot more sense. So, let's push for it to happen up here in the intro and we'll see how it goes. So, let's do this. Okay. Doug, can I just bring up one thing? We had talked about potentially having the the lead of the airport consortia the ACRES ACI participate in some way and they they can't physically be there but they could be there virtually. I don't know if that's what you would even be able to support but the key guy is in Canada and he wouldn't be able to fly all the way up there for that that he could participate remotely in some way. Interesting. Okay, let's talk about that offline because one of the things you can never really count on are the networks at conferences. So, let's talk about that because worst case scenario if maybe he wants to do like a couple minute recording that we could show that explains why this is useful to him in his particular industry that might be useful right there. That seems like the best approach. Yeah, we could talk about that one but we could probably make it work. Okay. Excellent. Thank you. All right, finally the serverless session 85 minutes. Chad told me he will not be able to make it for that. I believe he was going to give a very brief state of serverless overview. Is there somebody who would like to volunteer to cover his spot on that? Just to refresh your memory, I believe the intent here was we were going to have a couple of quick little presentations like Chad was going to say, you know, what's chain and serverless? I believe what was it?  Jude was going to talk a little bit as well and then after that we're going to lead into more of a bird of a feather type of session to interact with the audience to see where their pain points are, where they might want us to go from a serverless working group perspective in terms of what to work on next kind of thing. So these are all pretty much very short little intro things. Is there somebody who would like to volunteer to do the state of serverless since Chad can't make it? I could do that. Okay, because I was going to do it if no one else wants to but if you're volunteering go for it. Okay. Thank you, Scott. Okay, cool. Okay. In that case, I think at some point we probably need to just come up with a list of questions to ask the audience to prompt that birds of feather discussion but obviously we can wait until later do that. Is there anything relative to KubeCon you guys want to talk about now? Okay, as I mentioned on the previous call I did put the very rough draft presentations out there so you can see there. I put a link into each section here. There's nothing in there other than the title slide. Feel free to start adding your data or your content in there so people can start reviewing it and commenting as we go forward. Do we want to pick a date for when people should have at least the initial rough draft of their stuff already to put some timelines on us? Yeah, that's what I wanted to ask about. Is there a deadline? I know some conferences want the full presentation uploaded weeks before. Yeah. This one has a deadline. I honestly don't know what it is but I don't think there's any penalty for missing it. Typically in my experience people wait the last minute to get this stuff done and I'm okay with that because people always make changes the last minute but I want our working group to be able to review our content at least in the rough draft form at least a week or two before the conference if possible. So I was thinking of maybe throwing out a date of say the end of April by having the very first rough draft from everybody. Is that doable or are people too busy? Can we pick on somebody? It's a stretch but considering that conference starts in like very close to mid-May I think it works. Is it May? What's the date? It's a little after mid. Well let me ask you Scott, you probably have a fair amount of work signed up here. Is end of April something doable for you just for a rough draft? Scott, you're still there? Sorry, yeah. I was wondering if we have a deadline of end of April for the very first rough draft for the presentations. Is that something that's doable for your schedule?  Yes, it works. Okay, cool. I could just say silent means yes but I didn't want to do that. Okay, cool. Zoom keeps like auto-detecting my mic and muting me? Really? I don't know. That's weird. Okay. What other people think? No one's going to come down hard on us but I just like having dates because sometimes that helps motivate people. You guys okay with starting out with a date of April 30th? Actually, I guess let's push it out until April 30th. What if we just say April 30th for the first rough draft? It could be very, very rough. That's fine but at least sort of an outline of what you want to talk about so that we can tell the group on that Thursday which is May 2nd to at least look at it and see if the high-level topics that people want to talk about are consistent with what they think we should be talking about. Does that sound fair? Yep, sounds good. I prefer May 2nd because first of May is a bank holiday here and we're going to be putting last minute touches. Okay, we'll tell you what. Since it's only two days apart, what I'll do is I'll say May 2nd is a day for the rough draft but with the assumption that on that phone call that we have on May 2nd for the regular cloud event call I will say the rough drafts are there. Please review it to the whole group. My reason I was saying April 30th before was that would give us two days time for sort of an internal review before we open up the full group but we can go straight for the full group too. That's fine. No, that's a very good idea. April 30th is better. It's a very good idea. Okay, here we go. So hold on a minute. Let's see. Okay, I got a run. Okay, thanks Scott. See you next time. Okay, so rough drafts available April 30th with working group review starting May 2nd. Okay, I'll make sure to mention that to everybody to email or something. Okay, any of the topics you guys want to talk about. All right, cool. In that case I think we're done and Doug for you for the demo stuff like I mentioned in the previous call I'm hoping by the end of this weekend we'll have something that's a little more concrete in terms of actually running code for us to start playing with and then on Monday's call we can see where we are and see where I went wrong. Sound fair? Sounds good. Excellent. All right, cool. In that case I believe we are done. Okay, thanks guys. We'll talk next time. Okay, bye. Thank you, bye-bye. Bye. Goodbye.


Twice a day, like clockwork, we would be out-body surfing. We ended up starting this company after getting really tired of getting hit in the face with plastic pollution. Most manufacturers aren't just in the business of creating products. They also are in the business of filling landfills for single-use plastics. A company here in California is completely flipping the packaging paradigm. Let's go take a look. My name is Jeff Anderson. And I'm Dane Henderson. And we're twins. Full Cycle Bioplastics is the company that we founded that has a technology that can turn any organic waste into a compostable and marine degradable bioplastic. So conventional plastics are made through petroleum refining. So the stuff that doesn't go to oil and gas is typically made into what you see today, the bags, the forks, the food packaging, all that stuff. That is now either going to sit forever in a landfill or get tossed in the ocean and sit forever in the ocean. PHA is the new paradigm here. So PHA is both extremely compostable, much more so than PLA, and it's also marine degradable, meaning if it ever falls into the ocean, it actually acts as fish food or bacteria food and has no toxic effects. Aren't there already bioplastics on the market? PHA has been around for a while. We're not the first to make it commercially. The thing is everyone else who makes it commercially makes it out of really expensive feedstocks, like pure sugars or seed oils. What we do differently is we use organic waste as our feedstock, which is negative cost and it's available everywhere. So what are you able to make with bioplastics? This stuff can be used for all sorts of things. So whether it's durables, bags, to-go containers, cutlery, water bottles, shampoo bottles, you know, all sorts of things. At the end of the life of our plastic, the best thing for it to do is to come back to us. Then it will break back down and we can make virgin plastic from it. And if by some misfortune it is discarded onto the side of the road or in a river in the ocean, it will degrade harmlessly. I would say plastic has found a place here and will stay, but bioplastic can be a direct replacement, just a better foot forward with that same theme.


Hello and how are you all today? The question says a machine cost a company Rs 575,000 and its effective life is estimated to be 20 years. A sinking fund is created for replacing the machine at the end of its lifetime when its scrap realises a sum of Rs 75,000 only. Calculate what amount should be provided every year out of the profits for the sinking fund if it accumulates an interest of 5% per annum compounded annually. Here we need to use the value of 1.05 raised to the power 20 as 2.655. So let us write down whatever is given to us in the question first. We are given the cost of the machine equal to Rs 5,75,000. Its scrap value is given to us as Rs 75,000 so that means amount required in the sinking fund at the end of 20 years at 5% per annum interest is Rs 5,75,000 minus Rs 75,000 which is equal to Rs 5,00,000. We know that we can find out an amount of annuity by using this formula. Here I represent the rate of interest that is 5% per annum, Rs is the periodic payment and N is the time period. So on substituting these values we have 5,00,000 equal to Rs 1 plus i that is 5% that is 0.05 raised to the power N that is 20 minus 1 upon i. This further implies 5 lakh is equal to our bracket 1.05 raised to the power 20 minus 1 upon 0.05. Now the value of this term is given to us in the question itself. So on using that value we have our bracket 2.655 minus 1 upon 0.05 which further implies 5 lakh into 0.05 divided by 1.655 is equal to R that on simplifying gives us the value as Rs 173,71.60 as the periodic payment. So this is our required answer to this session. Hope you understood it well and enjoyed it. Have a nice day.


Teaching English in the Czech Republic, the Salary and Budget Guide This guide will help you answer the question, How much can I earn and save teaching English in the Czech Republic? You'll also find information on the local cost of living in order to figure out how much to budget for when making the move to the Czech Republic. The typical salary for English teachers in the Czech Republic Because of the huge demand for TEFL qualified teachers across the Czech Republic, the average salary can be anywhere from 18,000 to 30,000 Czech Karuna, currently US$700 to $1,200 per month. However, a lot of private language centers prefer to pay by the hour and it is common practice for teachers to work at more than one institute in order to make up a full-time schedule. Teachers in the Czech Republic working on an hourly rate make around 200 to 300 Czech Karuna, $8 to $12 per hour. How to earn extra cashed while teaching English in the Czech Republic? Many teachers in the country take advantage of the high demand for private language tutors. By taking on private students in their free time, teachers can earn extra money outside of normal working hours. The rate for private lessons will usually depend on your experience but is typically from 300 to 500 Czech Karuna, $12 to $20 per hour. Getting a work visa in the Czech Republic The Czech Republic is a popular teaching destination in Europe for teachers from outside the EU as it is possible for non-EU citizens to obtain a long-term work visa to teach legally in the country. The cost of living in the Czech Republic Besides the strong demand for TEFL qualified teachers, the Czech Republic also attracts English teachers because of the relatively low cost of living. Routine expenses such as groceries and public transport are a lot cheaper than you will find in Western European countries such as France, Italy or Spain. Cost of living in the Czech Republic, food If you eat out at local restaurants and buy your produce at local markets, you will be able to eat very cheaply in the Czech Republic Milk, 1 liter 19 Czech Karuna Eggs, 12 50 Czech Karuna Apples, 1 kg, 35 Czech Karuna Chicken breast, 1 kg 145 Czech Karuna Rice, 1 kg 35 Czech Karuna Bottle of water, 1 5L 24 Czech Karuna Bottle of Czech beer, 0 5L 36 Czech Karuna Cost of living in the Czech Republic Leisure activities Czechs like to hang out with friends and enjoy their free time When teaching English in the Czech Republic, you can be sure to have a great time outside of the classroom while exploring this wonderful country and culture to the fullest. 3-course mid-range restaurant dinner 750 Czech Karuna Quick restaurant meal 140 Czech Karuna 1-month fitness club membership 770 Czech Karuna Movie ticket, international release 180 Czech Karuna Cost of living in the Czech Republic Transportation Large cities have a fast subway network and the whole country is very well connected via trains and buses. Taxi rides are also not as expensive as in Western European countries. Metro ride 24 Czech Karuna Monthly pass, regular price 550 Czech Karuna Taxi rate per kilometers 26 Czech Karuna Start fare 40 Czech Karuna City bus 24 Czech Karuna Cost of living in the Czech Republic Travel in the Czech Republic and beyond The Czech Republic is world famous for its beautiful landscape and scenery and you should definitely take advantage of the low price of train tickets to explore the country. One night in a mid-range hotel 1000 Czech Karuna A train from Prague to Brno 2.5 hours 109 Czech Karuna Train from Prague to Vienna 4 hours 750 Czech Karuna Sample monthly teacher budget To give you an example of how an English teacher in the Czech Republic spends their salary, here is a sample monthly budget. Gross income, salary 25,000 Czech Karuna Average Rent, shared or one bedroom 8,500 Czech Karuna Utilities, electricity, gas, water 4,200 Czech Karuna Phone and internet 480 Czech Karuna Food 3,000 Czech Karuna Insurance 500 Czech Karuna Remaining disposable income 8,320 CZK, currently 370 United States Dollars How much you can save when teaching English in the Czech Republic? As you can see from the sample budget above, you will be left with approximately 370 United States Dollars after the average expenses. This amount varies, and of course, depending on your salary and location. However, it is true that you won't be able to save as much while teaching English in the Czech Republic compared to places in Asia, for example, where the salaries are generally higher and the cost of living even lower. However, you will still have the time of your life when teaching English in the Czech Republic because of its welcoming culture and exciting things to see and do. Take your TEFL Tezal in class course in Prague. Our ITTT has an in-class TEFL course in Prague, where you can spend four weeks learning everything you need to know about teaching your own English class as abroad. Are you ready to teach English in the Czech Republic? Apply now for your TEFL Tezal certification course and start teaching in a matter of months. Speak with an ITTT advisor today to put together your personal plan for teaching English abroad. Send us an email or call us toll-free at 1-800-490-0531 to speak with an ITTT advisor today.


Are you stuck in your content creation because you can't figure out which topics you should be creating content on? Well, here's my recommendation. Just start creating content. Just press the record button. Just start writing on the things that you feel are important, especially as you think about what you are building a business on or what you might want to build a business around. What topics are important in that field? Thinking about the potential customers or clients in your business.  Just start creating content on these things. Don't worry about whether you are focusing on the right topics, the right keywords. Don't worry about that. That may be stopping you from growing this muscle of content creation. Would you need to grow anyway? Even if you had all the perfect topics, you still have to learn how to do video or how to write a blog post or do it on a consistent basis. That's another muscle that we all need to build. Those of us who are serious about serving the world with our message, start creating content, start sharing it, and then once you start sharing enough content, you're going to be able to then observe which of your content pieces does better, meaning it gets more engagement than your other content pieces. Then from that data of noticing which ones are working for your audience, then you can start to put those into categories. I've been doing random pieces of content and maybe I end up talking about 20 different topics, but I noticed that my audience particularly loves it when I talk about topics two and five and 12 or whatever it may be. You see, put the content out there first, share it as widely as appropriate as you can, and then start to notice the data of what's working, and then you can decide on the categories, because then it's not you deciding on the categories, it's the market, it's the audience telling you what they want you to make. That is the best way to decide what categories or topics you ought to be creating. So now let me talk about how I'm doing it in my business. I've been creating videos consistently now since the middle of 2015. In middle of 2015 I gave myself a challenge to do 100 videos basically Monday through Friday until I finished, and then after that I started doing these three times a week videos. So I've made a lot of videos, I've written a lot of blog posts hundreds by this point since 2015, and recently, in the past year really, I started to realize, oh, I want to be writing my blog posts. I make my videos so that it inspires me to write my blog posts, and I write my blog posts because those are potential chapters for my books. So that's how I'm thinking about it. So I make three videos a week and therefore three blog posts a week as well, and one of my blog posts or end videos is thinking about my upcoming book that I'm going to be, you know, putting together. And then the second video or top blog post is thinking about the book after that, because I've already done enough content where I notice what my audience wants, and so I've kind of created a list of topics that I love to talk about and my audience likes for me to talk about. So then I basically have decided that those are going to be my books. So I make these videos that inspire my blog posts, which then become book chapters. And the third video of the week and blog post of the week is basically I kind of reward myself and say, I can talk about whatever I feel is important or whatever I want to talk about. So I hope that's helpful. Just get going with your content and then decide the topics and themes later.


Kevin, you guys started out 15 for 20 from the field and put up 41 in the first quarter. So what was working so well for you guys offensively in that first half? This team, they do a lot of scrambling on defense. So I think we just moved the ball, made the extra pass. I was able to find good shots. Joe and Kyle got us going to start making shots. So that's always good when we make our first few threes. But the ball, let me see if we finish with it. 27, it felt like we had more than that. But we moved the ball all night. Was able to find a good shot. And then you were big on Wednesday about downplaying expectations for Tegers, getting him out, and seeing how it goes. Just what would you make of the 17 minutes he gave you guys? I loved his minutes. He has a knack for finding the basketball. And he cut into the rim well, offensively rebounded a couple times, running the floor. So it's only going to get better for him as he get more reps under him. Looking forward to him playing out there with us. Really solid defensively. So he just gives another big body. And just happy he's playing again. I know he loves the game. Kevin, you guys won four in a row and seven of the last nine. Just what's changed during the stretch? Shots going in. We got a couple favorable matchups with some teams being a little banged up there. But all in all, I think we're moving the basketball well, which we're covering for each other on the defensive side of the ball. And we're playing as a unit on both ends. So we continue that. Then we'll be trending in the right direction.  Just what's it going to take to deal with a team that's solid on all ends of the ball? Yeah, we got to be solid. We can't make mistakes ourselves because they capitalize on it. So we just got to be solid. Be ready to play. I'm excited about it. Kevin, you obviously know what it's like to come back first hand from a serious injury. Missed that much time. What is that feeling like that TJ went through tonight when you've been out that long, and then you're able to do what you love again? I can't truly speak for TJ. But you get a little bit of anxiety before the ball is tipped, just leading up to this moment. I'm sure he had this date circled for a while now. So you just get so anxious to play. And now that he's out there and got his feet wet a little bit, he can relax. So it's always tough leading up into that first game back. But he showed he's a poised guy. So he showed that he belongs out here. It felt like he didn't really miss too much of a two years he missed. He didn't feel like that. But we still got to be patient with him. We still understand that he had some tough injuries. And he spent a lot of time away from the game. But he looked great to me. I believe you guys are three and 0 against the Raptors here. What advantages have you guys had against this team? Which ways do you think you've attacked them well? Just because they do swarm so much defensively. Yeah, I think they throw a lot of different defenses at you. They might box in one, triangle two, pressure all game, pressure for a few minutes out of time, full court trap. So they just try all types of stuff. And I think we just stay poised through it all. I mean, we used to have teams throwing all types of defenses at us. So we'd go through it in film, we'd practice it. So we was able to hit the extra pass tonight. We made some great looks. We had 27 assists, but I felt we could have had 35, 36 with the amount of shots that we missed that were open. So yeah, we just stay patient when they start to swarm. You guys, especially when things, quote, aren't going well, you guys frequently give up a lot more attempts than you guys are taking. Either giving them away on the offensive glass or turnovers. But when you guys are holding teams pretty much even on the glass and not getting beat up on the boards, just how dangerous can you guys be when you're basically even playing middle of the pack in terms of your offense and terms of your rebounding? Yeah, I mean, we got a lot of threats out there to shoot the ball. So that keeps the defense on the heels. So if we win a possession battle, we always give ourselves a chance. And I think a lot of teams come in our building saying that look is going to be hard to keep up with them if we just try to make it a shootout. So let's jump the game up a bit, run and crash the glass, run and jump us double team so we can try to get turnovers to speed them up. So a lot of teams feel like they can throw a little bit more game mix at us because we score so fast. And so we move the ball so well. So they got to keep up. But for the most part, we figured it all out. We learned as time goes on. We're trying to figure out how to play off of each other through different defenses and has been working so far. But we got a lot of ways to go.


Kiev considers renaming Russia. Ukrainian President Vladimir Zelensky has instructed his government to consider renaming Russia as Moskovia, an unofficial designation used centuries ago. The move comes after a petition insisted that, by using the word Russia, Ukraine is endorsing a dangerous claim that its neighbor is a direct descendant of Kievan Rus. In a statement, Zelensky said he had turned to Ukrainian Prime Minister Denis Shmygel with a request for the comprehensive processing of the petition, which had gathered the necessary 25,000 votes to be considered. The issue needs to be carefully worked out both in terms of the historical and cultural context and from the perspective of possible international legal consequences, with scientific institutions taking part in the process, the Ukrainian president added. Commenting on the move, Russian Foreign Ministry spokeswoman Maria Zakharova stated that it was further evidence of an attempt to create an anti-Russia out of Ukraine.


Hey all welcome back to the fire and water cooking channel. I'm Darren and today I'm gonna do a cook that I don't think I've done yet on the channel I'm gonna do some pork loin chops. I bought a couple of big pork loins the other day at Costco They they always have some pretty good deals on the big pork loins And I usually cut one up into a big roast and I cut some of them up into chops And I caught I cut some good size probably a little over an inch and a half Thick chops the other day and I went ahead and cut them up and seasoned with run-and-wild peach rub and I vacuum sealed them and I'm gonna actually gonna cook these up sous vide today And then we're gonna throw them on the camp chef Pellet grill. We're gonna use the sliding grill function to get some char on them and I'm gonna use the char The char wood Hickory Pellets they got the charcoal in it. So we're gonna see how that turns out and I'm also gonna make a little sauce for the end and a little moho Honey type sauce. I have some moho marinade that I usually use on some pork and chicken I'm gonna make a little sauce to put on these Pork chops when we finish them I'm gonna mix it with some honey and some garlic and some other stuff So I'm gonna go ahead and get these pork chops because they're ready. They're frozen solid So they're ready to go into the I'm gonna go ahead and throw these in the sous vide bath at 136 for four hours and then we're gonna toss them on the grill. So 136 we'll get these nice and probably more like a medium rare more medium And then when we throw them on the grill, we're gonna let them get a nice crust on them And they'll finish up around, you know medium to medium well still plenty juicy and not overcooked and dried out So I'm gonna get these thrown in the sous vide bath. I will see you guys The things I like about this pellet grill so much this campshift There's a see I got all these pecan pellets in here right now I don't want to use those pecan pellets to Cook these pork chops tonight.  It's gonna be a finishing sauce And what I'm gonna do is I'm gonna take about a half a cup of this mojo marinade Which has got a lot of citrus stuff in it already. It's got some orange juice. It's got some lemon lime garlic It's a pre-made marinade It's more of a for Cuban pork or Spanish style stuff and it's got a lot of Citrus and All that in there. So I'm gonna take about a half a cup Maybe a little bit more maybe more like two-thirds of a cup of that marinade And I'm gonna add in About Quarter cup of clover honey And I'm just gonna go right in there eyeball it, but I would add about a quarter cup Maybe just a little bit more than that maybe a third of a cup of honey and This could be the taste you can sweeten this to taste. So that's about a quarter about about a third of a cup right there And then I'm gonna take one lemon and Just kind of squeeze it into it those seeds out You could use lemon juice too, you don't have to use a fresh lemon, but I just happen to have a couple fresh lemons And I take two limes Do the same thing just kind of That's about good right there Some little limes And then we're just gonna whisk it up and then we're gonna put it on the stove and heat it up some so they get Okay, I got the pork chops out of the sous vide and I'm gonna get ready to I'm just gonna pat them dry because you want to get a nice Sear on them from the sliding grill On the camp chef get some of that charcoal flavor to them So I'm gonna make sure they're padded real dry and I'm just some Valerie season salt and just a little bit of that and not a ton of it Just to get a little bit of salt saltiness to them because we're gonna put that real sweet sauce on So I'm just gonna go ahead and put just a little bit of season salt And maybe just a little bit of pepper That's about all now. We're gonna get them tossed on the grill So I guess that grill is up to 400 degrees and what I'm gonna do is open up the sliding grill lever here And what that does is pull the heat deflector back and opens up the flame So I can cook on the direct flame Then I'm gonna put these pork chops on And let them get nice and toasty These are already cooked so they don't have to be out here long. So just enough to get some color And some smoke That's it. I'll be right back. All right. I'm gonna go ahead and flip them the Grill says is it five sixty or four sixty four So it's getting pretty hot Remember these are cooking right over that flame So they're getting some color to them Not bad at all For the sliding grill feature here, you know, that's the sliding grill feature works great. It's You know, it does have a limited area that it covers because Pella grills have that, you know small area that Firepot is but it seems to work pretty good for me. All right We're gonna give those another minute and a half or so on that side and we'll be right guys These are done and I got my sauce here and I got a really good sear on these And like I said, we weren't cooking them on the grill to get them done. They were already done We were just getting this nice sear on them got a really nice color and we're gonna go ahead I'm gonna go ahead and put a little bit of the sauce. You see it did Thicken up some I'm gonna put it right on these And I tasted it already and it's nice and Citrusy and sweet Tastes really good Put a little bit of that on there. I'm gonna cut into this one right here Take a bite and you can see it's a nice done this on them They're not well done or overcooked at all. They're not dried out There's not much pink in there, but I really don't like pink pork too much But they are very moist still mmm And the sweetness of that sauce with the salt and pepper And a little bit, you know, you can taste the peach rub a little bit, but it's mostly washed off But they are perfect Yeah, nice and moist They're not They're not too done and they're not too rare. So go ahead and try these out guys Especially, you know, I love the feature of that the the Camp Chef grill on the sliding grill because I can taste a little bit of that charcoal taste on these and It's the only charcoal grill I know of that you can actually pull back that heat deflector and give it a nice sear on there over the direct flame So check out our other videos. Make sure you like this video Subscribe hit the notification bell and I'll see you guys again on our next video. Thanks again


So you guys might have seen my video that I shot last year which was a day in my life Where I walked through exactly the habits and the strategies and the scheduling I used so I don't only have a successful business But also do a doctorate. So I'm in medical school, but for traditional Chinese medicine And one of the things that I got was a very interesting comment from a couple of people That was a little bit negative and it was along the lines of the fact that I never have free time No time for play no time to really do that much and This brings up a very very good insight and a huge teaching point that I want to share in this video Because 99% of people will not do one thing that will dramatically change their life and that's what we're talking about today here Hey guys, Alex Hein author of the book master the day FYI if you get the book send me a receipt to my email I'll give you a hundred dollar bonus course for free. That's more material on the books You can check that out now one of the things if you're interested in Becoming the quote 1% and I just mean someone who's improved their life to the point where they're doing amazing in all parts of their Life the first link in the description is a free journaling worksheet on how to plan out your best year ever With some of the goal-setting strategies I've used here. So you click that link below download that you'll also get an email Every couple days on how to use goal-setting to change your life. So what is that thing? That most people will not do that thing is that most people will not do Whatever it takes to live a better life, you know, the first thing that this comes up to is that most people like the idea of success More than they like the actual process I heard someone else say this in a very wise way where they said everyone likes the idea of being a rock star But very very few love playing and writing music every day You know when I first started building my business and even just getting into self-growth stuff at the start I would be like, okay, you know, I'll work on the weekend There's like scrubs is on or there's a new show on or my friends are going out to get drinks since Wednesday night I'm gonna go out dinner But it would always be the weekend when I would work on all my self-growth or my business stuff Which was much harder and much more long-term thinking was required But when I became really committed to the goal of building my business, you know, what that meant for three years I came home after work went to the gym and I went to a cafe for three hours to work in my business Seven days a week. I saw my girlfriend at the time on the weekend for three years Only on the weekend before we were seeing each other during the week once or twice for three years. I Did that I came home to work on my business just on my business no Netflix No, Chellen no none of that because I wanted to have a better future for myself. I wanted to have a better life But so many people that write me are like how I used to be We work on things only when it's convenient and not because we're very committed So in the same way, you know when people criticize me for being like no time for fun relaxation or play Like no shit for lack of a better word. I'm in a medical program and I'm running a business like did you think that would take 15 hours a week It's like 50 hours and then 20 hours is more realistic and then you throw in cooking every day going to the gym That's it like that's a six-day week right there and then you throw in friends and that's my whole life right now So I don't think people fully understand what it takes to live a better life It doesn't mean some insanity like this some crazy work hours. It doesn't mean that but sometimes it does and if it does That's the price you've got to pay. All right Now the second one is that most people only work on their goals when they want to right? This is just building off of the first thing I said, you know when I researched Michael Phelps I was studying a little bit about how often he trained and how often he prepped to be in the Olympics now This dude is a high achiever. He's one of the most meddled Olympians of all time, right? He's no slacker and what he did was he spent five to six hours a day training Every single day for five years So think about that for a sec imagine how hard it is to go to the gym one hour a day Five days a week for one month. This dude did five to six hours per day every day for five years That's no joke Right, that's 2,000 days almost and yet we struggle with doing a little bit each day And the point here is not for me to beat you up or for you to beat yourself up But for us to understand what does it really take to change your life? To become the best that's what it takes but for you guess what it may only take one hour a day I'm not asking you I'm not like Gary Vee over here work a hundred hours a week sleep six hours at night look exhausted all the time I'm not saying that but Find that one hour per day you can commit to building a better life yourself Rather than complaining and blaming and hating the world and judging successful people because you want to be there Why not dedicate that one hour per day?  No at church Different kind of church Your friends want to hang out no come in an hour your shows on doesn't matter skip the show or dear one hour earlier in the Day so 99% of people I know for a fact will not do what it takes to build a better life But you can use this like the fuel that I used in my own life because I knew that one in a million people Would be willing to do the work every day I knew that one in a million would be willing to not see their girlfriend During the week for three years and that is why I am now building a life that only one in a million can have And if you think this way if you adopt this belief and think you know what that's great That I know how the 99% think but now what is the achiever think and how do they live? Then you become that person.  What is the great person do when I'm asking out a girl or asking out that guy? What is the average person do? What is the exceptional person do and this can become your guiding mantra for your life to help? Just skyrocket it to the next level 99% of people won't take action on their goals every single day Will you now if you want to prove it to me that you're that one in a million Like I'm your daddy and you got to prove it to me to earn daddy's love Then download that free worksheet before it gets any weirder and fill that out to plan your best and most inspiring year You do that you're going to be already the one in a million because most people don't even set goals So download that get started and then come on over check out my last videos there and there