Hi, George. Hey, how's it going? It's all good. Today, we won't have work done on the call. So let's give it a few minutes. Let's see if anybody else is going to connect. Cool, no worries. All right, let's get started. Share my screen, starting with our hyperledger disclaimer, and maybe also removing this bot off the call. There we go. All right. All right, so welcome to 13 April, 2003, RSVCX Community Call. This is our anti-trust policy notice by Hyperledger Foundation. I mean, to do that. Yeah. So for anyone tuning in, we have these calls every Thursday, Thursdays, 9 AM UTC. If you would like to come and discuss something, too, you can also just connect and talk with us. So to kick off the meeting, just to check, George, am I coming clearly? Is my internet fine? You cut out for about five or so seconds just then. I see. Let me try to fix that. Hopefully the radio waves will feel more welcome when the door is open. So let's see if that helps. All right, so good first issues. So just kind of like quick recap there, just to also periodically keep this as a theme to keep good first issues in mind. So there was one I've created recently about updating time, create dependency, as there was automatic update which failed because there is actually breaking changes. And I saw just 15 hours ago, we had a new purist contributor, SWAPTR, SWAPTR, with a contribution here to basically update this dependency. Seems like there's still something failing, some clippy, some unit tests. So I think we'll still have to take a look at that. Nevertheless, thank you, SWAPTR, for these contributions. Always exciting to have new people on board and having contributions. We also have other two good first issues in progress right now. One is from Andy Wayne, who updated once again his branch, tried to address some of our previous comments. But nevertheless, there's also something to be addressed here. So looking forward to getting this merge in. And then next, yeah, there was a short discussion here on the attribute encoding from Stevane. So this was going on for a while. And Stevane was very persistent, still always addressing our reviews and comments. So Stevane will be busy for a bit, but he still plans to work on this in the first week of May. So that's all good. And yeah, that's, I guess, all of our open good first issues right now. It's a good to, if anyone has idea, even outside of this call, or to create, to come up with some good first issues, that would be awesome. Next up, a small update on our high-pledge mentorship program. I'm sure that there are some people tuning in, curious, particular about this part. So just to kind of remind the mentees, the applicants, how the program goes. So right now we are in the period of time where people can, the mentee, people who are interested in the mentee can send application. And there's instructions here how to do that. So that's all the way on to 10th of May. Then from 10th of May all the way to the end of May is basically for us to select the mentees and notify them about the acceptance. And starting June 1st, 23, there'll be the working period until mid-November. Yeah, and in the meantime, there's some evaluation kind of dates as well. And yeah, I also wanted to talk a bit about the projects a little bit more because there was people asking me to tell them more about these, both of the projects we have. People who are interested. So let me put a picture here. I'll stop sharing for a second. OK, I'm sharing back again. So picture I had here. It's not a previous picture. I kind of get the work done. It's a picture I drew while on call with one of our applicants. So basically, we have two projects. We have the next gen mobile wrapper and we have message mediator. So the mobile wrapper, that's on this picture marked with a blue color down here at the bottom left. So that's kind of the scope this represents. It's a next generation mobile wrapper on top of Aries VCX enabling use cases where people want to build presumably mobile wallets supporting Aries protocols and anum creds and so on. So this will be the meat of this job would be to write this layer and finish. There is a POC right now available, but there is a lot more work to be done there. And the scope would be mainly to finish this part. And in addition to that, create Aries mediator client. That's essentially very specialized, Ditcom API client to communicate with the mediator server. And basically from this UniF5 wrapper then there will be auto generated Swift and Kotlin bindings. And part of the scope of the project is also build a small, it could be very simple Android application as a demo. It doesn't have to do all of the protocols, but it'll be nice if you can at least accept an invitation. That's kind of the baseline for a good starting point for anyone else to start adding other protocols and other features and so on and so forth. And here on the top left, I mean, this could just kind of denote kind of explaining, maybe a textbook example of how things work in the Aries ecosystem, in Aries deployments. Usually you have some consumer, I'll call her Alice here with a mobile device, she'll be holder of a mobile wallet capable of Aries protocols. And she'll at least want to communicate with institutions, for example, bank or any other institution. But the thing is, as you can see here, there's also one box between them. So usually Alice can easily communicate with the bank because bank has some sort of public endpoint exposed and there's kind of an example here that the two pieces of information which Alice needs to have in order to communicate with other party through Ditcom is service endpoint, which will be just URL, where Alice can send messages. Other will be a public key, which she uses to encrypt the messages. That's kind of in that show what you need for Ditcom. And then from the other side, obviously if bank wants to initiate or the institution wants to initiate the conversation, communication, it would need also the same set of information. However, there is no public endpoint, there's no direct way to directly send message to Alice's device. If we forget about maybe like some IPv6 stuff and things like that. But we assume the device doesn't have any public endpoint. And so the architecture is similar like with mail servers where we have a server where you have an account as a consumer, as Alice and this service can receive messages on your behalf. So there will be a mediator box here. And that's also where every mediator client kind of plugs in here. So for Alice to communicate with the mediator and pick up the messages, which she might have received while during the night, you need some sort of client to talk to this box. And that's what this blue box down here from the previous, from the first project is doing. And now moving on to the second project, that's the mediator itself. And that's here with a purple color. So here is a mediator a bit zoomed in. So just get any idea what might be in there. I will kind of look.  After you receive messages, they're typically encrypted. So in the decrypted, then once some sort of decrypted message pops out, you need to take a look what kind of message it is. And for that, you can use Aries VCX to support, you know, processing some of these messages for some of the Aries protocols. So the green ones are the ones we already have implemented in Aries VCX and you will just kind of build on top of them. The red one pickup protocol is currently not present in Aries VCX and therefore the scope of this purple project would also be addition of pickup protocol to Aries VCX. Although I don't expect that to be a huge, huge effort. Well, and then essentially, as you can see, you have three families of messages you might be receiving. Based on what kind of message it is, you do something else with it. If you receive an external message addressed to someone, you would, which is common use case, you'd simply pretty much just stored a message on under the, you know, linked up with the recipient. And then second use case is picking up those messages. So once the recipient here, it will be Aries in this example. Once Aries come online, she would try to contact mediator using the Aries mediator client to pick up the messages. And that's essentially this pickup protocol. Well, this pickup protocol is specifying. There are Aries RFCs on GitHub, which I'll be adding here just after our meeting, just after this meeting with further information about these RFCs, but that's pretty much it. Obviously you need to have some sort of persistence layer to store these received messages so they can be picked up later by the proper and authorized recipient. It's also important to keep in mind scalability. So this service should be horizontally scalable. So you should try to avoid using some sort of in-memory storages, making sure that the storage is, the state is distributed and that there won't be any complications scaling this out into entire cluster of mediator containers or something like that. Yeah, George, have I missed anything? I don't think so, that's really great. Yeah, is this image available anywhere or will it be? Yeah, it's not. My original plan was to make it be prettier for the meeting, I completely missed it. So I just had to pull it out in this uglier form, but I'll be putting into the meeting notes so people can find it there. Yeah, looks great to me. Awesome. So let's move forward to the usual stuff. So let's start with the overview of the work done. So we had this extraction of Aries VCX core and by Mira. And it's all approved, but you had a great, great catch there that this was originally ran with the SKI, which is something we discussed last time. Yeah, I totally missed it. So I put a rerun and why it's not running? That's weird. It's still skipped, although I did remove it. Wait, that's strange. Let me try to rerun it again. Okay, we'll see how it goes and hopefully we can rerun all jobs. Yes, sir, rerun all, okay. Okay, we'll see. I guess we'll see in a couple of minutes if this goes as expected. So yeah, but maybe to talk a little bit about this PR. So, and actually I have one more picture and I just need to pull it out and find it somewhere. So I'll stop sharing for a second just to give this PR additional context. That was basically how we iterated to this idea that we should even do this piece of work. We were discussing with Mira how should we go about this resolver implementation? And yeah, this PR ended up with as a sort of pre-preparation work. Let me find, it's a pretty picture we had. I think I got that image now. Sharing again, sorry for a little technical hiccups here. Okay, and there we go. So what this PR is doing is extracting a portion of a portion, a big portion of code which is previously part of Aries VCX. In particular, the profiles and the trade which are shielding off particular implementation details about storage, a ledger client and credential implementation. So this is all extracted out. And the reason why we even did that was that we wanted to basically started thinking how to build the idea resolver. So we thought about some like trades here which is not really important here. We can leave that for a separate discussion. But basically we came to obvious realization that when we build did resolver, we'll need access, for example, when we build a resolver for did solve method, obviously we'll need access to server and ledger. And we already have these profiles which contains this API and functionality in Aries VCX. But behind those profiles, but in order to access them, obviously we would either have to do like make a did resolver dependent on Aries VCX which doesn't make sense because then we would have like cyclical dependency Aries VCX and did resolver, did resolver needs Aries VCX which would lead us to basically placing did resolver into Aries VCX. However, we wanted to have it as a separate create so people could use the idea resolver. We're gonna implement in projects perhaps without necessarily using Aries protocols. So that obvious conclusion was that if we extract out all these profiles including the specially the ledger profile then we can just have it as a shared dependency. Aries VCX can depend on these profiles as it's using them today. Aries VCX can use the idea resolver and the idea resolver on its own could also rely on these profiles. So people who want to use only the idea resolver can use, can do so without having to bother being concerned with the Aries stuff at all. And so yeah, so then we extracted this as a separate component right now as like one huge create. I don't know, maybe I'm not sure if it would make sense to split it out further. I don't think there's a need for that at this moment. But I don't know, perhaps if somebody, I think it's possible to go in in the future where somebody might be interested in, I would say only using ledger and doesn't care about wallet and critics at all. So then would maybe actually make sense to take out and the ledger component as a, the ledger profile as a create on its own which would kind of basically be a facade behind the BDR tools and the modular libraries. So yeah, that's pretty much it. Let's just wait for the CI. Although I have the bad feeling it's keep skipping these jobs. Yes, and I don't know why. Maybe we need to like push a new commit or something like that or sort it out after the call. Other than that, there was some small cleanups of dependencies. This one is still pending review and the other one was merged. There was dependencies which were not used and also a bunch of that code which was deleted. Next up there was dropped support for the legacy format of serialized through Verifier, state machines which have been created by a version before 0.53 release. So there's a upcoming PR for the 0.54 release. And so therefore, since we dropped the support now in 0.54 we will no longer support those old serialization formats. You'll have to follow the migration strategy provided in 0.53 release to essentially re-serialize the state machines. That's it for what we've done since the last call and then we have some work in progress. We have a messages integration. This has been open for a while. The recent refactoring of the extraction of Aries VCA score kind of shuffle the cards as this has to be rebased. This has to be rebased and also Bogdan is not here but I know the challenge right now is just to get the tests integration tests up and running. We were doing a whole bunch of internal testing with these changes in Apsa and it looks good. Seems like it's working but obviously we want to maintain the CI as is. So there's still some work pending to sync up the tests with the changes. And lastly, I suppose, apart from the smaller things there's the type state pattern holder and I saw there was a bit of a discussion here between Bogdan and you George but fortunately I didn't have yet chance to take a look here. So I guess I'll take a look. Perhaps you have any comments on this one? Although you already wrote a whole bunch of stuff so I should probably read it first but still it's a space for talking. So if you want to somewhat comment it or if you have any new thoughts. Yeah, do you want me to show you sort of what I have so far and maybe? Yeah, for sure. We have time so why not? I'll stop sharing. You can see that okay? Yeah, it's all good. So like I originally started that PR before we had the revised sort of guidelines how to make types of patterns. So it had a lot of sending messages and things on that line which we don't want anymore. And also that PR started before messages too existed. So it was getting pretty outdated. So recently I've just been working on a new branch trying to follow the new guidelines. And yeah, so basically I'll go over some of the things some of what I have so far. So it's mostly based off the original holder handler but following the new guidelines. So for instance, none of these are filled out yet. I've just been drafting the states and transitions and want to get them approved before I go any further. But yeah, so firstly the first state is proposal prepared. So you can reach this state by initializing a new holder with your proposal data. So this is basically the holder beginning the protocol saying that I want a credential with this data and then after they create the holder and enter into this state they have the ability to get the proposal message which then they can send on their own account. So this part's good because it means that no errors can happen. There's no chance of any errors. And then so after they've assumedly got that proposal message and sent it out and then received an offer back and offer credential message then they have the opportunity to transition into the next offer received phase. So this is what this API does. And originally I had this as returning like an areas VCX error. But Bogdan mentioned that you may as well do it like this where the error type is the holder in the failed state. And yeah, in the PR I'd written it like that. And the reason I didn't go straight for the holder failed state is because it seemed a little scary to implement but I don't actually think it'll be so bad. And yeah, so the reason that this can fail is because there's ledger interactions and also a non-creds interactions that need to happen as part of this step. So there is sort of a chance of failure. And yeah, this is sort of the first maybe controversial thing. I was hoping to get yours and Bogdan's opinion on which is this API right here. Even though it's a transition API I have it as taking a reference to self, borrowing self rather than consuming it. And the reason for that is if this was consuming it and it ended up in the failed state now the consumer has no reference back to the original. But if this is borrowing then if this ends up here then they determined that it was only a soft failure maybe it was the ledger timed out a retribal error. Yeah, I mean like what I noticed here or what was like what is on this line I pulled this off with my like conception understanding of the guidelines of the stuff we discussed is basically here like you are returning and like there's two possibilities of what kind of holder might be returned whereas and I mean we might have to just update the guidelines maybe just something we didn't like discuss enough and so maybe we have some different understanding but my understanding would be that we always kind of only either return like the new state successfully or we return error but not actually the holder in like a failed state. And so I would assume what I would originally expect would returning result where the error portion of the result would be yeah just some sort of every VCX error or something like that and then it would consume itself and then it will be up to the caller to either retry it again if it makes sense or just enter the failed state manually because they see they have got an error from receive offer so there's no way to go about it just entering the failed state. Yeah, so that's sort of how I wrote it out here where this should take in an error as well but they have to opt into transitioning into the failed state. Is that sort of what you were expecting? Yeah, yeah, yeah, basically I think what you have drafted there is more closer to my expectations. Yeah, see this was Bogdan's response to that. Yeah. Right, so I think we will have to go through this make sure that we are aligned on this. I think I mean I like the original approach I think with the error and then going to the failed state on your own sort of that way you don't have to take the reference and it's kind of nice and symmetrical like. Well, I think you still would have to take a reference because if this results in error then you've still lost self, still that problem, right? Oh yeah, right, right, right. Yeah, I see, I see. So yeah, what do you think that does this seem okay? Like it's not perfect type state transitions because you're keeping the original. I mean, I know Bogdan was like had lots of concerns about this and it was trying to find good like typing solution to kind of figure out is like how to prevent using the state machine after maybe you was already modified. Like if you take a reference here and you return new state machine, how can you kind of prevent the developer making mistake by using the old one? But I don't know, I mean it'll be definitely like nice to have something like that. At the same time I feel like this kind of like guard controls can be added later somehow. I don't know exactly what would be the solution, but yeah, I mean, I think it makes sense that like you might want to, for some reason want to still access the original data, like you don't want to just lose it and we also like this, I mean, otherwise, if you consume self, the developer wants to maintain the original data, they will have to make a clone ahead of time and juggling two state machines kind of at once. Yeah, yeah, exactly. Yeah, I think if the developer really wants to keep the original state, they can do that no matter what we can't really prevent them from doing that because they can always clone or serialize and deserialize before calling some consuming API. I think this was another option Bogdan sort of alluded to where it consumes self, but the result is either the new state or it's an error, where it contains the original state plus, you know, the error. And that way, yeah, it's pretty maybe kind of complicated, but yeah, it ensures that if they do get to the successful state, then the original is consumed. Or maybe it's inefficient, but perhaps even like always returning the previous state and the new state and that way you could just like, I guess the signature would be simpler because you could just return some sort of tuple of holder, you know, previous state and the new state, previous state would be whatever the previous state would be and the new state would be either the successful state or the failed state. And we wouldn't have to have the manual failure transition method. So basically result and then result and in the result. Are you talking about something like that or? Yeah, but basically it would be a tuple. Maybe the successful case, right? Like a holder, like it would return a result and then in the result, it would be successful, you know, successful result would be tuple of previous state. Oh. Well, I think if it's successful, yeah, we don't want to give them, if they succeed, we don't want to give them back the original state because it was successful. So there's no point in them keeping the original state. But if it fails, then we want to give them back the original state in case they decide that it's not a hard failure. No, yeah, I was off. I thought that we could return tuple of like previous case, previous state, new state, just every time, but then you wouldn't, you can't really express it in RAS because like the new state can be one of maybe multiple states, it can be the successful one or the failed one or maybe even something else. So that's no go. So yeah, it looks quite complicated in the way. This way the signature might be more matching, but at the same time, there is some beauty in it too, I think. And especially if you can have like the methods, the transition methods like symmetrical in terms of always just consuming self and then it's not like sometimes itself and sometimes it's reference. Yeah, I'll be definitely nice property. So you're saying you prefer this sort of signature to this one where it's taking a reference, but no two. Come on offence, I'll have to think about it a bit more. Okay, yep, cool. I'll think about it and join the discussion on the issue. Cool, okay. I'll post this update on the thread, but yeah, I guess the rest of the state transitions are fairly straightforward. Yeah, this is another constructor as well because you can technically start the protocol in from the offer state. So you send off an initial offer rather than you sending off an initial proposal. So yeah, similar transitions, you can go back and forth between proposal and offer if you're negotiating the credential details that's part of the protocol.  And when you're in there, you can fetch the message and then send it off on your own terms. And then when you're in this state, it's assumed that you've sent off your credential request message. And then once you receive the final issue credential message from the issuer, you receive it and enter into a credential received state. And then once you're in there, you can store it and storing it results in you transitioning to finished. Right, but the question, where you receive issue credential and store credential received. Yeah, so this is something different to this is another controversial thing that is different to the original holder API. I guess you receive it and then maybe once you're happy with it, then you store it. What do you think? Just be receive it and store it and then transition. I'm not sure at the moment what will be the implementation. Maybe what would receive issue credential? What would it actually do? What kind of stuff? Pretty much nothing, but stuff away the message into the state. Maybe it's not worth it for it to be a. Yeah, maybe you receive. And there could be some like still maybe validation. Like what if the credential you received is actually what you expected, right? So you wouldn't just store store some something you don't want in your wallet. Yeah. Yeah, I guess I guess it could be also think about it. But one more question, which is popping, popping in my mind is remember that the holder is also sending back like acknowledgement message at the end, isn't it? So, yes, so this is maybe another controversial thing, but you transition into finished and, you know, maybe we have it like this and get rid of this one and this transition straight into finished. But once you're in finished, then you can get the act message because I wasn't really sure how to represent. The intermediate step. Or whether sending the act is a part of the finished state or presented as like the step before you're finished. Yeah, seemed a bit awkward to represent that. But this isn't the best either because I don't know, someone might see finished and assuring that they're done and not bother sending the act message, even though they should. Yeah, right, right, right. Yeah, but I think it's I mean, it's it's aligned with the fact that we don't do IO anymore.  I mean, usually with all the other steps within the protocol, it's the same way, right? You like get the request message or get proposal messaging. So the same way you get the get the ag message and you send it with some like it's up to the consumer to send it somehow, right? And maybe just a question. If the if the if the act of sending the message or allegedly sending the message, it should if it should leave to some sort of like next next state. Yeah, I'm not even sure if Holder is obliged to send the ag message or if it's only if the issuer asks for the acknowledgement. Yeah, yeah, in the original implementation, it only sends the act if there is the please act flag. But I'm not totally sure if that's 100 percent accurate to the RFC needed, but that was the original implementation. Right, yeah, I assume it's probably that way. Maybe question is how it works with the two point of protocol of the issuance. Yeah, yeah. So yeah, if if the act messages in the finished state, this was another idea I had where it returns as an option and it it only returns some if the please act flag was true one way to represent whether you should be sending the act message or not. Yeah, right. These are like great findings. I mean, you're doing pioneering work here. As we wrote out those guidelines and now you're now you are kind of doing the first rewrite trying to follow them and trying to tweak it to change the approach we've been doing following before. So yeah, it's definitely valuable just to have this. I mean, I assume that implementation of the other protocols will be much easier as we kind of dig through these like big question marks of like how to do this, how to do that. Then we have it answered. We can just read up the same approach everywhere else. Yeah, yeah, exactly. I think so. I mean, like, I guess these questions about some things are result types and whatnot, consuming or not to consume. I'll post them in the thread, but I think they won't block me too much just proceeding with the implementation now. They're just sort of minor details. So I'll go ahead and just start implementing if we're somewhat happy with the shape of these, apart from the questions. Yeah, I think I mean, I think it looks looks good. In general, I'll just have to take a closer look at the discussion. Cool. OK, yeah, that's all from me. So for taking up a bit of time. No, it's all good. It was it was a good, good talk. All right, then let's let's. Let me show my screen again and I'll just add notes here. I had like a high level we just covered. So there was a question kind of open question about the return types in case of error. And then we also kind of touch on the. Self was self and then we had. I had. So separate states. Received credential. And stored credential. And then one more point was the acknowledgement message at the end. OK, so we have these of the table. This was really nice discussion and moving on to the next one about the upcoming work. So we have Mira current and work on the deep parser, the resolver. We have yourself working on the credential holder and basically all of us kind of going through these questions which arise. So I'll put it. You know, that that's that's. Well, I'm talking about upcoming work, but. I got a little bit tangled up here, upcoming work. Well, Mira will start to work on these in like in a close future, I suppose. So that's why it's so an upcoming work. And then we have the type state pattern, I assume, once maybe this is in a little bit matured PR, we might pick somebody might pick up the other type state pattern implementation here. And I guess that's like the close future ahead of us. Still as for the. It's for the getting rid of VDR tools. I think the like the main next point is to get rid of the like it is a rewrite issuer with the credits. And once that is done. We might be able to start trimming down a VDR tools such that it would only essentially contain the wallet, the original wallet. And we could consume, consume in the client and credits implementation from the modular, modular, modular libraries. Yeah, and we have four minutes left. There is a bit of a tiny discussion point here about the trade naming. So just notice that we have a bit of an inconsistency here I think, or do we? And maybe I was wrong. It seems like all of the crates are with underscore just that the repository name is with a dash. And then also the name of the credit itself is the dash. Maybe this is what this will trigger me to to add this point there. I just if we name the credit this way, maybe we could just name the directories, use the dash for directories as well. And then I guess the second inconsistency is that for the other projects, for example, agency client, we also use underscore for the directory name. But here we also use underscore for the trade name of the package name. So I guess we should kind of find, unify this approach, although it's just like a minor thing. I guess my personal suggestion would be since we named the repository aries-vcx. Then we could just and also we call the package the same way. We could just use dashes everywhere. And also I guess when I'm looking at the other dependencies we depend on, looking at how this is being done in an ecosystem, is that in the credits is also with the dash. And but I know, I mean, this is kind of, there is no single, I think, recommendation in the RAS ecosystem. I saw lots of crates with underscore, but also lots of crates with dash. So I guess it's kind of up to the individual projects and crates, what kind of approach they adopt. What do you think, George? I'm like, I'm browsing the internet at the moment trying to find what the idiomatic way is, and I can't find an answer. Yeah, because for example, Serdi, I think he's using underscore. Yeah, Serdi underscore, Jason. Yeah, that's what I thought of, but then others have dashes, so I'm confused. Yeah, yeah, it's 50-50, I feel like. But yeah, we should definitely stick to one. I have no preference, personally. Let's take a look at the LVDR tools here, what kind of dependencies is here. A lazy static is underscore, Serdi is underscore, but log derived. Oh, that's a small credit, though. All of the indie stuff is with dash. So they're consistently using dashes, is that right? Yeah, it would appear also in the credits. Well, let's take a look at in the, maybe there is no dash in the name. Anon creates RS, right? Ah, yeah, good. RS, I think they also have, they also have dash. Yeah, repose the dash. And then the name of the package is actually different than the repository name. Yeah, I think I would go with the dashes, since it looks like it's popular in the hyperledger slash indy slash ery's. Yeah, ery's asca is a dash, that's great. And our repository name has a dash in it as well, right? All right, so there will be some big rename, I mean directory renaming, but I guess let's leave that after some of these big PRs are merged here.  All right, oh, and then one more point, although we are just on time, this one is short. I was just thinking, what kind of, I was thinking it would be nice if we use maybe some shared prefix for all the projects which are incepted under the ery's dcx repository. So for example, messages or like, pretty much everything. So I was thinking like if that we could prefix, I'm not sure about the directory names, but at least like the crates themselves perhaps. I mean, once we start publishing this, I'm 90% sure it probably messes me. Already exists on crates. So we will need some how to distinguish ourselves. All right, so I was thinking ery's vcx, ery's dash vcx dash whatever, or maybe I don't know, experimental brainstorming idea, like some abbreviation like abcx or maybe just ery's dash something, ery's dash messages, you know, I guess there's multiple things one could come up with. Yeah, is there a reason we couldn't go with just ery's, you know? No, there's not a reason. I'm just wondering if then ery's is not bit too specific though, because for example, let's say we create like, we create now this resolver and it's going to be like ery's did the resolver, but people who might want to use it, you know, they want to use the like rust implementation of some of the other resolver. It's going to be like ery's did the resolver as that's not volume. I don't care about ery's, this seems to be something else, right? So I was thinking maybe something less like specific or at least at the face value, like avcx, it's like some string, you know, whatever it means, like it could mean ery's vcx, but avcx messages, like nobody would, if somebody consumes it, maybe they wouldn't be concerned about this avcx. Right, yep. I don't know, I just, I'll just leave it like an open question and maybe send a poll on this quarter or something, because with the others, I just wanted to like put this, put this topic on a plate to start thinking about it as the new crates are being born now. All right, anything else from your side? No, not for me. Okay, awesome. So we got it all done and it was a pretty long agenda today. Yeah, so thank you, thank you for taking time to join. I know it's late now, so I should get some dinner. And now we'll see every other, everyone else again next week, 9MUTC, go for it to join. Thank you, George. Cool, thank you. Cheers. Cheers.


This is Perla Shaheen for Cal TV News and you're watching part two of my interview with the new chancellor As you know, there have been recent controversies on campus regarding Republican speakers like Ann Coulter and Milo Yiannopoulos How do you plan to work with the Berkeley College Republicans to Make sure that violent uprisings don't occur in the future First I believe very strongly that Speakers of all ideological persuasions should be able to speak on campus that the right of Anyone to speak is the right of us all to speak We will make sure that the events are secure by working with campus of the campus police what I hope to do is Create both a series of events around free speech at the very beginning of the term So the campus community has the opportunity to engage those issues So the students are really excited to get to know their new chancellor. What are your what are your hobbies? Well, I love music.  I try to play every day Don't always succeed in doing that. I walk every day and of course being an English professor I love to read and I know you've published two books both on Victorian poetry So I guess who are your favorite poets my favorite poets I'm not I'm going to disappoint you by not naming Victorians My favorite living poet is Mary Oliver whose work is just deeply moving to me I love the classic modernist poets T.S. Elliott W.B. Yates Wallace Stevens Well, thank you so much for meeting with me and I wish you the best in the coming years Thank you very much. Pearl. It's been it's been a pleasure talking with you


Hey everyone, this is Melissa with the stockswish.com and welcome, welcome to AFOP. Boy, what a fantastic golden gap this turned out to be today. Really didn't even think that this would make a new low and it's almost doing it. This is like, look at this, $12. Well, didn't get it here. Talk about dream targets. So let's go over this. First things first, even with the big bar in this, this is actually an entry for a swing trade or a core trade. Targets, $9. This is a real target, not a fantasy target and not even a dream target, actually. I don't know the timing of the gets there, but this is an overnight position here and here now that you could do for a longer term trade. Swing trade, really. This is totally feasible as well, possibly $7. Look at that. Stops over the high of the gap. Okay, this is actually really a very good, bearish gap and the target on this today, this is a dream target for $12. I mean, I was looking in the morning at 13, 12.50. It was very realistic, but what happened is that it fell off the planet. It fell off the planet and I was talking about this earlier in the room, selling, selling, selling, selling, selling, selling, which come into this today and you can see it here. I mean, this is all selling, hard, hard selling. So let's go over it in the one minute chart. And if you're doing a swing trade, well, first of all, if you're doing a day trade, you're in the day trade, you're flat before four, but if you wanna do an overnight, you take the day trade entry, okay? Your position sizing is different because your risk parameters are different for overnights because your leverage is different for overnights, okay, for your sizing, but the entry would be the same, okay? The entry would be the same for the swing trade or the core trade. You would take the day trade if you want to, get out of a portion of the position and hold some of it into the larger move or if you just wanna do the day trade, you're in and you're out flat as a short or if you want to do the core trade, just no day trade, okay? You still enter the position with only your position sizing for the overnight with the entry on the day trade. That's why you still have to know how to rate the gaps and know the entry for the day trade because you really, you wanna get it at the best price possible. It's just one of those things. So, really what happened here was the stock open here and had a huge sell-off here into the open. I was watching this because in real-life time, this looked like a bonding tail that had green head and the five, okay? But then it did this top-and-tail thing quickly here, settled down and came down really quick and set up here right at the reversal time. There was a lot of time in the stock open here There was only one problem with this today and I bet it isn't even, no, it's not even there anymore now, it's two pennies. The problem with it this morning was I was just too spreading. It was just way, way, way too spreading. Look at the volume in this now though, pretty amazing. Look at that. So this morning it had a spread into this beginning period. That was wavering. Like one minute it would be a penny, next minute it'd be two pennies, next minute it would be eight pennies and it would be 10 pennies. The bottom line is you must take the trade and price in the maximum spread. If you don't do that, there's a chance you get taken out when the stock moves up and touches on a number that's not even really the stop-out. But with the spread it might be if you don't have it priced in. So the proper thing to do is to take the trade and you must stop in the maximum spread. And if you ever do this and you realize you didn't have it right, like because this was a moving spread this morning, one minute it was a penny and the next it was 10. So if you ever miss it and say, oh no, it's really not a penny and then you see it's more just change the stop. And unfortunately that might mean that you end up risking more if you already sized yourself and you took it or you can just quick take some out. In this case here, if you took it you were rear up right away so there really wasn't any concern. Came down here, broke a little of the day by two pennies and then double-bottomed and then rallied up here and actually I called a second trade right in here. So you could have actually taken half off, lower the stop, taken the whole thing and retook it. Came down in here, went and broke $13 and this was a really nice move. I mean this is a dollar plus move here. This is a dollar 12 cent move in here, dollar 13. Then what it did was this thing were backed up right in here. And look what it did after that. I mean this is absolutely insane but after the retest of resistance here the stock actually dropped another dollar from there. Look! And this is all in the morning period of 10.30. I mean once it broke 12.50, here was the bar. Yeah, here was the guy. It was a 10.25. Once it broke this, I mean this was just like a, this was a dream target here at 12.50 from where this opened. But once it broke 12.50, $12 was likely and that's where it is. And I look at this, this is, no it's not gonna break the low. That's really it for the day, it's 12 bucks. It's 2.39 here, this is done now. But this is not done for the overall move. So you could enter it at 14, you know 14, 12, 14, 11, 14, 10 for the swing trade and you put the stop over the high of the day. It's a paper stop because you're watching the trade when you're in swing trades but you have to understand how to rate gaps to know that this actually, this gap is gonna hold to get to the next number. That it's going to be able to be positioned, you can take as a swing trade to get in it, take the position at the area, size yourself properly and take the trade to get it down to the $9 target. That's very realistic. Now, because of the bar, the size of the bar I had here today, I just, you know, I don't know the timing of it gets to something like that but it may have a rest day or back up for a little bit but it's not gonna get over the high of today. I mean it's 100% conviction because of the gap and the way that it broke and just everything about it. So beautiful, beautiful, beautiful golden gap and AFOP really nice and all of this did it's of its own accord today. It completely did it of its own accord today and this really worked out very good as a day trade and can be done as a swing trader or court trade. Swing trades at $9 and the court trade is to seven bucks if it wants to go there. I think you have to do have target areas when you're in overnight's but this is one of these gaps. Even though the bar looks like it is today you could actually take a longer term position here overnight and it's had a really beautiful fantastic move as a day trade and just, you know, word of note when you see something with a spread price it out the maximum level and just know that you're gonna have to do that. This is really, let's just see the size of this bar over here. Oh, that was $2. Yeah, look, $2.35. So this is really like the biggest bar in this chart here, I think. Really did go to a dream target today. You know, it just goes to show you, you never know. I mean, you just never know. Look, this one here was over two. This was like two, 225, this guy here. I mean, you never know. And that's why this conception of risk to reward in reference to taking the positions and then with the spreads, you have reasonable targets. Some days you take a trade and you have the area. You have the target. And by the time the setup happens and it triggers or you see the spread, it goes and it doesn't go on to make three Rs. You end up making two and you end up having to get out of it because you see the reversal signer goes right to the first target and you gotta take it. But then there's days where you have a trade that sets up and you have a very reasonable target and it not only goes to that, it goes far beyond your expectations and you think that it's barely gonna make the three on the first setup because of the stop or the spread or whatever the case may be or the entry. And then all of a sudden it makes 10 plus Rs. This is trading. This is trading. When selling comes into something and that's what happened with the AFOP today, it's really, really pushes the stock down to go to these larger numbers. And it's a great thing if you like to short. And I do love to short. And I think if you don't know how to short, you need to learn. We're in a market right now where shorts are getting paid. Okay, shorts are getting paid here. And if you don't understand how to short, as a trader, you gotta learn. Doesn't matter if you do day trading or swing trading or court trading, no one should be afraid to short. People need to learn how to do it and understand what it means. It's really not that difficult to understand. I think learning what trades to take and what things to short takes understanding, which is why I teach the class, but I believe that strongly in anything I trade even if I would do along. So anything you trade, you need to be picky with the entries and with the stock symbol that you do. But I find that people shy away from shorts because they don't understand them, whereas they love to do longs. You gotta know how to do both. You wanna make money in the market quite frankly. And I prefer to do shorts because they have huge bars because they move very quickly because they tend to move fast in the morning. And when Connick sets into a stock, the red goes and runs like the Dickens. So I love that about shorting. And that's really mainly what I focus on. And there's a lot of people that just don't even know how to do it. So I think it's one of these things that you've got to decide, hey, I think I gotta learn how to do these shorts because I'm missing out here if I do. And so that's one of the reasons I'm specializing in these areas. It's a niche because I love to short them just really very good at it. And not only that, seeing when something's gonna break and seeing the break before it happens, which is a great thing. And here's the AFOP today. So beautiful, beautiful, beautiful, fantastic AFOP. This is Melissa with thestockswish.com. This is AFOP, golden gap of the day here in the Stockswish show, Trading Room went to the Dream Target and is an entry for Swinger Core trade to $9, which is great. Really nice move on this AFOP today and some follow through will be here whenever it sets in, which could be about the next week even. I mean, who knows? Would this kind of sell off here today and things possible? And the market is still showing weakness here today to be honest with you. More so than I thought. If you'd like more information on the golden gap class, email me at melissa at thestockswish.com. The next class is this weekend, February 8th and 9th from 9 a.m. to 5 p.m. Eastern time. Email me for more information for the sign up documents if you'd like to sign up. Again, a great time of the year to learn how to short, very, very important, to know how to short specifically in this market. Yeah, and I'm the one to teach you, that's for sure. So have a great day, everybody.


hey guys got another Subaru in the house this time it's an o1 rs 2.5 five speed check it out i always like the front of these cars well all of it most likely the coolest in preza ever but this one this one's a little a little rough and when i say a little i mean well it's got some rough edges well like here here here here can actually look inside the trunk some racing tail lights oh oh yeah it's symmetrical or is it a new venting system so your stuff in the trunk stays cool more stuff weight reduction here that's the plastic stuff the side skirts for something just what is this oh i see okay more of this weird stuff on top of the roof a few dents here and there well at least the bumper is decent uh no no no it's not no i like these vents yeah that's a lot of miles it's got 200 000 miles abs light is on no check engine look at this carbon fiber finish is this factory oh wow i didn't see this before oh shoot all right we just i'm sorry i didn't just put it back there there that's good should be fine so why is this thing here here and why it's not at a scrapyard well let me explain this is actually going to be a third Subaru that i'm gonna more or less prepare for ice racing remember the first one was me and look was that it's an 06 in preza 2.5 in in manual we already took it twice for ice racing and once for an autocross summer and you know during the summertime events then another buddy liked our idea and also bought an 06 i was going to say sti 06 in preza the wagon i did a series on that head gasket stuff a lot of work on that one on this one i'm not taking the engine out near no no there was oil leaks everywhere i did take this thing to a shop and i did power wash the engine bay basically engine on top and all of it underneath the transmission the engine you know because it was just underneath it was covered with oil on top not so much a little bit here and there but underneath it was you could not see them the metal parts at all it was it was bad and supposedly this is an engine from a forest there don't know what year supposedly it's got 70 000 miles on it it's maybe more i don't know it's probably it's probably might be maybe 170 so this thing will see nothing but ice it's never going to get registered the weight reduction in the back that's that's actually a plus probably may want to remove the glass on this on the other glass the actually i never checked if the sunroof works where's the button oh i'll be i'll be done oh it's just this okay this actually works holy cow this is cool okay so there is no glass so this should not be that heavy well all the components in there are all right so we're just gonna leave that let's look underneath the hood that's by the way how you open it this is clean like i said power washed this whole thing so yeah the check engine outlight was on for actually have it written down for once i wrote something down code p0507 high idle idle detected something and after the wash without disconnecting the battery or resetting the ecu the light the check engine light it's off fixed so guys we actually got a list going on battery tie down which i already bought low coolant so possible leak could not see again could not see any coolant usually it's it's white powder or greenish powder or bluish powder whatever somewhere you know if it's a small leak could not see any of that it was just covered in oil uh engineer filter that's covered in oil it's low on oil so it burns oil which is you know typical front inner axle boots uh we actually have both front axles new steering boots steering or rec and pinion boots those are ripped off ripped ripped apart front and rear struts the fronts i'm gonna get kyb xlg i think for the front and we're gonna use our o6 impresa springs and and mounts so that should be interesting see if it's gonna actually fit same for the rear struts but we're gonna reuse our old well they only have not even 54 000 miles on them on the rear struts and we're gonna reuse the springs as well now you know the the whole point of washing the car was well to make you know work on it easier or more more enjoyable and now we can look for leaks so after i'm all done i'm gonna run it for a little bit or actually maybe even before we'll see and look for leaks uh the rear diff is leaking probably not gonna do anything about that that's the check engine light that's off spark lock do like you know maintenance just check spark locks clean out the throttle body i'm sure there's oil in there one of the headlights doesn't work wipers actually they come down too low and they keep hitting they keep going like this which is going to be annoying oil change you know filter obviously the wash is done we can actually make a check and no handbrake the rear right brake line is cut probably not gonna do anything about it do i right battery tie down twice every tie down all right done cool what's wrong with my okay nice fog lamps don't work front lift tire has a leak i'm gonna take the ac compressor out possibly the condenser and all the lines depending on how easy it's going to be we're gonna fix that exhaust by probably cutting it and change fluids like maybe brake fluid transmission oil and rear diff oil and in the process i'm gonna try and remove things that are not necessary for ice racing for example probably this you know one or two pounds all the ac stuff this guy here this line this is newer ac compressor these covers this is actually this is not even connected over here uh here battery that needs to be addressed with the battery tie down which is this guy here i already have a few parts what else maybe the center console is going to get removed maybe i don't know radio maybe speakers the door skins and the seats in the in the rear oh yeah that seat needs to passengers seat needs to come out because there's a hole in the floor right in there it was actually cut out but the owner before he installed sound thatening okay or dampening whatever you call it and he kind of ignored this big ass hole and just stuck that straight on the floor right here about this big yeah all right guys so i don't want to make a series out of this you know 10 episodes because you know every time i do a Subaru it's always a serious can't be one video you know almost forgot i've read it down rear trailing arm bushings and them jesus bolts whoops bolts yeah some of you already know i'm gonna show you something because it took me took me a bit to figure out what's wrong i actually had to a body move this wheel you know when it was up in the air back and forth with two hands and you know move it really hard so if you look from you know got a top down view let's let's say this is a straight line over here you can look at the body over here look at the where the wheel is i'm sure you can see this this goes in this comes out look at the other side this one not so much yeah it's pretty obvious and because the steering wheel is actually it's like this it's bad you know when i say jesus bolts i actually can show you i actually have a set for my sti because i'm gonna have to go through that again guys don't buy these at the dealer these are china okay but you know once when i put these on new i just just smear it with anti-seize or some some kind of grease especially in this area here and this because the middle here that's exposed it's that's in between the knuckle and they get stuck right at the bushing inside on both sides and you just gotta do some cutting heating everything whatever you can to get these out so these are on rock auto i think they're like 10 bucks each and you know i don't know now but maybe twice or three times the the amount at the dealer all right guys now i gotta park it somewhere closer and put it on jack stands guys car is up just enough let's take a look underneath so this is after the wash you can kind of imagine how it looked before look at this thick grime everywhere that didn't come off but i'm not seeing any fresh oil yet so no major leaks this is ripped that's also leaking but you know not badly so to save on it a little bit i'm gonna replace these boots both sides also look here the axle boots also ripped and that's at grease right there and check out this work look look at this exhaust work there's more here but this this is you know serious stuff over here uh yeah okay we're gonna ignore that for now another boot that's ripped and it's more of that grease from the grease inside the axle but it's not that bad i mean i've seen worse there's the hole i was talking about so it needs to be cut a little more and i'm gonna weld i gotta remove the carpet the seat and i'm gonna weld a plate over it from the inside it's just gonna be easier brakes are fine not touching the brakes look at this front strut right side leaky so i've gotta go now this is the rear right it's not leaky but it's old it's making noise tires are decent now this side strut is new besides the spring they have reused the spring but this strut is brand new the new ones for the front are going to be for an o6 impressions so the o6 impressions is a bit heavier than this i think by 300 maybe 400 pounds not sure so what's going to happen is i'm gonna get a bit stiffer and that's always good for racing and this is the front right or left i should say also making a little bit of noise you know you can go out on this as is on this suspension you know but chances are something's gonna break after the first or second event and then you know you're out in wisconsin two 300 miles away from home and you know you're out for a few weeks at least i actually don't know where to start maybe i should start with the engine bay or the suspension or the exhaust maybe the floor wipers weight reduction let's pop the trunk ah man the the trunk release doesn't work and the key doesn't want to come out it's brilliant oh it's out yeah didn't open hmm smells like an old basement got a spare tire look at this venting system yeah that's a lot i may weld something over this area but you know the fuel neck is right here so maybe just use rivets instead of welding it's in there another spare nice so two spares full size what's in here we should have a rusty jack oh look it's been ventilating for a while hello what's this here what is this cranking power signal noise eliminator and adjustable output reducer what rca connectors and why is this wired what the hell is going on over here is the wire to the speaker as well what the hell yeah that's that's not gonna cause any issues you can adjust output output output and input signal noise eliminator maybe oh maybe for your sound system subwoofer that buzzing noise that you sometimes get not sure all right i'm gonna leave this open and throw any weight reduction pieces in here after some weight reduction i'm gonna quickly check for leaks but before i do that let's listen to the intake noise check it out see it's shaking we may need a a set of engine mounts and a transmission mount quickly check for leaks brake cleaner see that's gonna happen so basically around the intake looking for the food or pms to drop just like that so if there is a vacuum leak around the intake gaskets throttle body gasket you know anywhere the intake connects to basically or anything to it with a gasket just spray brake cleaner all the houses nothing let's see what got removed intake box ac compressor all the or ac compressor bracket uh i forget what you call this thing the uh expansion no tank no i don't i don't know maybe cross control and all the ac lines and the condenser this thing actually is not too bad i mean it's seen better days but it's not too bad and this intake filter look at this oily but for some reason the throttle body is not oily enough it's actually pretty clean it it was clean so the guys that replace this engine probably moved the filter from the old one to the new one then we plugged off the vacuum line for the cruise control here look at all this space obviously there's gonna be an intake here you know not sure how much all this weight 30 pounds maybe 40 maybe once i'm done maybe i'll weigh it i don't know probably not but we'll see and i managed to lose a bolt this self-tapper here that was right here the smallest screw and i lost it i mean i even was organized this is all i took off and it's not not in here oh yeah almost forgot this is an issue too this doesn't lack no matter how hard i push down these tabs are done gotta do something about this guys if you want to see what's going to happen to this car once it's done subscribe to this channel like the video dislike the video just just do something and this isn't going to be anything special okay we're not going to be restoring the this thing and putting you know 1200 thousands horses whatever okay this is just a simple rip well hopefully simple hopefully simple repairs kind of actually to think about it saving it from the from the junkyard really give it give it another life on the ice racing track all right that's it see ya soon


Hey EmberConf, it is good to be here. So, let's see what we got going on here. The art of Ember app deployment. My name is Luke Milia, for those of you who I don't know, I live in Manhattan with my wife and two daughters. I write a lot of Ruby and JavaScript, some Objective C, and when I'm not doing dad stuff or coding, I love to play beach volleyball. I'm the organizer of EmberJSMYC. You might have seen some footage earlier in the day. Please come and join our community. We'd love to have speakers from out of town, so don't hesitate to reach out and schedule something. I run a fun kind of hybrid business where we have a product as well as do you Ember Consulting? If we can be helpful in any of those sides, let me know. Let's jump into it. So, how we deliver software has evolved over time. I would say this is kind of a fair way to say that it started, and it evolved. Cassette tapes, this is really where I got started playing games on Balditari. Spent a lot of time with these guys, and then if you looked in your gift bag today when you checked in, you probably had one of these guys in there, actually looked a lot like those.  And it didn't start off kind of that way, but once it got going, it became pretty amazing. And so delivering software for most of us became how do we deliver via the web? And in the beginning, we just static HTML sent from a fairly low powered server to the browser. Eventually that became dynamic HTML sent from some more powerful servers to the browser. And then came the rise of the server side app frameworks. Again, delivering representations, HTML representations of that app state with each request to the browser. And finally we came to today with Ember Comp where we're delivering an HTML and JavaScript payload and then interacting with an API but really having the entire run time in the browser. And we may take what I just said for granted, but of course, William Gibson said it best that the future's already here but it's not evenly distributed. For as many of us as are here in this room, there are many more people out in the industry who have yet to arrive at this kind of browser app paradigm. And for many of us here in the room, we are still holding onto some of our deployment techniques from these server app days even though we've moved to this new paradigm. And that's what I wanna talk about today. Because after all, we no longer use CD-ROM duplicators to deploy software. This is kind of a funny picture and the reason I included it even though it's a little blurry is that in my very first software company which kind of started around the dawn of the web, this was getting one of these was a game changer for us. I mean, it changed our lives. But we also no longer deploy FTP files individually. Anybody recognize this program up here? That's awesome. Somebody at least as old as I am. So what is the web server, the server web app deployment approach? Simplified it's copying all the files to servers, restart the server processes. Pretty simple, for bonus points, you can do that copy files step more elegantly.  And you're probably gonna wanna do a rolling restart to avoid downtime. So the question is, is the server app deployment approach right for Ember apps? And you can probably guess by the fact that I'm up here talking to you that my answer to that is no. And so let's look at why. Let's start with the real basic flow here. So browser makes an initial request for your Ember app, request index.html from your server. Your server comes back with an HTML response. And that response contains within it a script tag that points to a fingerprinted JavaScript file. So in this case, app-abc123.js. So the browser parses that page a short time later, makes the request for that JavaScript, comes back to the server, server says, yep, got it, here you go. Ember app boots, all's well. But during deployments, this doesn't necessarily go so smoothly. Because there's a moment in time during a rolling deployment where that request for your HTML comes into the server, gets back a reference to app-abc123. The request is made, and right at that moment before the request is made, your deployment infrastructure has flipped over traffic to the new server. And so the new server comes up and in that new deployment, you now have a new fingerprinted JavaScript package, app-def456. And when it gets the request for app-123, you get 404 not found, user gets a hiccup or your QA team, they refresh the page and they're like, oh, everything's fine, we'll just ignore that. But obviously not a great experience. And so the lesson in here is to keep static assets working during a rolling restart, if you're using this traditional approach, somehow you gotta keep both the old and the new versions of these assets around for at least a few minutes during the deployment. One way to do this, which many of us probably do, is deploy these assets to a CDN and just don't remove the old ones for a while or maybe never, considering storage costs these days. So another aspect to think about is how users interact with our apps in this browser app paradigm. Because today it's not uncommon for a user to be on your site for five, 10, 15 minutes in this one kind of page load, if you will. And so what happens during this when you're doing a deployment? Well, the app boots, gets its HTML and JavaScript, user starts doing their thing, requests some JSON from the server, and then around that point in time, you decide, hey, I've got some nifty new feature I'm going to deploy, you deploy some new JavaScript and an API change to go with it. And of course this user who's on this yellow timeline up here doesn't have the new JavaScript, right, because they didn't refresh the page. And so when they next try to make a request to that API, assuming that you have some sort of breaking change there, they're going to get some sort of error. And so the lesson here is that whether we think about it this way or not, we have multiple versions of our Ember app in use at once. You have the new version that new users are getting and you have the previous version that users who have been on the site for a few minutes are using. And so we somehow need our API to remain backwards compatible for at least the length of a user session. And so what I'm going to submit to you based on what we just looked at is that the idea of versioning your Ember app and your server API app together as a single version number with a single release process is a lie. And we can embrace this fact, choose honesty and give our Ember app a separate repository, a separate versioning scheme and a separate release process. And we can learn some lessons here from the way we think about the native app ecosystem here. It's kind of taken for granted that you're going to have multiple versions of a native app out in the wild talking to your API. And what you need to do is to keep your API working for those older clients. For some period of time, you're probably going to decide to end of life them at some point, but you certainly don't want to do that kind of each release that you go from the app to the app store. And you would never consider, for example, trying to time the release of your API change with when your app gets approved by Apple or gets through the Android submission process. That would be pretty silly. So we can learn from these native apps and see that this requirement buys a certain amount of freedom and a bunch of decoupling. So for example, you might have multiple apps in the app store talking to a single API. You might have beta builds that are out being tested running against your production API. And we can learn and embrace these things. We can and should do the same approach for our Ember apps, assuming that we are versioning and deploying these things independently. But there is a big workflow difference between native apps and Ember apps. And that's how apps are launched and how they're updated. And the key difference here is that instead of an app store in the OS being responsible for updating and launching, what's responsible here is HTML. HTML you can think of as the bootstrapping engine for your Ember app. And this probably seems pretty obvious, but when you follow through the implications to what does it mean for your deployment, turns out there's some pretty serious implications. So what do we need to think about for these HTML pages? HTML pages that are bootstrapping our apps need to point to fingerprinted JavaScript and CSS, but they can't be fingerprinted themselves. They need to be at a stable URL. They have a certain amount of order significance, so you wouldn't want to load your, say your app bundle before your vendor bundle. And if you're using a strategy bundle and strategy like that. And they're also a really good place to provide kind of environment-specific configuration to your Ember app that you don't necessarily want to bake into your JavaScript. In addition, if you can serve up this HTML on the same domain as your API, you get to sidestep all of the course complexity that comes along with having separate domains for those. Finally, caching should be minimal to none so that when you do want to deploy a new version, you're delivering it to new users ASAP. So the conclusion here is that HTML should be managed and deployed as part of your static asset build. So that's really part of your Ember app repo and build process, but it somehow should be deployed to your API server, your app server. And ideally, importantly, updates should not require redeploying the server code and it shouldn't require restarting server processes. And back when we were first building Ember apps, we were deploying our API and our Ember apps together and making a small JavaScript change or even a CSS change meant a five to 10 minute deploy process for what really amounted to static assets, which is kind of insane. So here's the kind of a sketch of the idea. We're deploying our, on the bottom here, we're deploying our JavaScript, CSS, and images, our static assets to a static asset server, serving those out to the browser. And then on the top, we've got our API server deploying, serving up API requests, any kind of non-Ember dynamic pages, as well as the HTML for a JavaScript app. And so the question is, how do we get our HTML from our Ember kind of diverse CI environment onto that API server? So one possibility is we could simply copy it up to the file system. But in a lot of modern deployment environments, this is ephemeral, so that's not really a great approach. We could deploy to S3 and have our API server kind of read that HTML out of S3 and serve it up. And that's viable, but S3 reads can be pretty slow and we certainly want this page to be fast. And like we said, to have a very small amount of caching in the mix so we can deploy quickly. So what's a good kind of low latency, persistent place to put this? So we already had Redis in our environment and that turns out to be a pretty good fit. It's not the only fit, but for us it was a good one. So for example, as an example of how this looks as a full environment, this is YAP implementation with the Rails backend. We've got our HTML being deployed into Redis, our Rails server reading that HTML out of Redis and serving it up.  And this process turns out to work really well and not only does it solve the problems that we looked at earlier, but it also opens up a huge world of emerging possibilities. So what are some of those? Well, one of the things that we realized really quickly that was possible here is that we could preview before activating. So when we deploy a new build, so a new batch of HTML pointing to these static assets into our server environment, we don't necessarily have to start serving up that immediately to our users. Instead, we can kind of keep it there and serve it up only given a particular query string. So for example, a release query param, identifying a particular release that we wanna preview. So here a developer can look at their new code running in the production environment talking to their production API server before any user sees it. And so the level of confidence that you have when you actually decide to flip that switch is pretty substantial. You're pretty confident that the world is not gonna blow up at that point. And certainly when we talk about deployment, we like to take those steps with confidence. So we can also do something really interesting which is because we have this HTML passing from Redis through our API server or app server to the browser, we can take advantage of that moment and do a little HTML rewriting if we wanted to. Now, why would we wanna do this? Well, here's an example. This is an example of Rails controller. Obviously works in any kind of backend. On line three, we're grabbing the HTML. And on line four, what we're doing is we're serializing the JSON representation of the current user. And then we're sticking that into a meta tag that comes down with the HTML. And what that means for our app is that as it's booting up, it doesn't need to kind of wait and do an Ajax request for information about the current user before it can make some initial decisions about routing. Do I show a login screen or do I route immediately to the content that the user's looking for? And this is just a nice kind of boost to that initial experience.  Adding CSRF tokens perhaps, including dynamic analytics params for things like Google Analytics, Kismetrics, et cetera. As well as embedding dynamic configuration to control things like feature flags. That might simply be setting a global that you're consulting to determine whether a flag's enabled or disabled. Closely related to this is the ability to easily do AB testing. There's two styles. There's the one using the kind of feature flag style I just described, where you can bucket users into an A or a B, turn a feature on or off, depending. The other one we used when we did a kind of full-fledged redesign of our Ember app, and we said, man, it would be nice to A-B test this before we cut over, because there's some dramatic differences. Well, so what if we deploy into two different Redis buckets, so have two kind of current HTML paradigms. Bucket users into an A-B test using our A-B framework, and then serve one up and one to one group, one to the other. So by the time we actually did fully cut over, we felt really confident that our redesign was indeed an improvement. And finally, I don't love this as a paradigm as a UI, but sometimes it's appropriate. You can use the fact that your server's being notified when a new version of your app is deployed to communicate via WebSockets or whatever your push infrastructure is down to your browser to say, hey, there's a new version available, you should refresh now to take advantage of it. So all this stuff, what I just described to you is some ideas that I've been talking about for about a year now, kind of in public first at RailsConf about 11 months ago. And since then, a bunch of people have stepped up and run with a lot of these ideas and created open source implementations around them. So I wanted to take a look with you at some of those open source implementations today. Now there's a bunch up here, not gonna go into depth into all of them, but the first thing that I did to kind of start to filter these out was to say, look, we want to be developing apps in Ember CLI and it makes a ton of sense to be building our deployment tooling on top of what Ember CLI already has to brings to the table. So let's filter this down to just the Ember CLI based apps. Now out of these, there were three that really embraced this kind of assets, HTML distinction that we talked about earlier and those three were Ember Deploy, Frontend Builds, and Ember CLI Deploy. And so I started doing some research and kind of looking at the implementation of each of these and it turns out that Ember Deploy and Ember CLI Deploy share the same kind of idea of having a core plus plugins architecture. And so for example, if you remember the slide where I talked about deploying to Redis, you may not have Redis in your environment and you certainly wouldn't want to put it in just for this. Maybe you have another low latency store, Mongo or Cassandra or even a Postgres or MySQL will do the job fine for this. So turns out that both Aaron Chambers and Michael Klein who developed these two projects came to that same conclusion like this should be really should be pluggable. And it turns out that Frontend Builds started life off as a fork of Ember Deploy. And Frontend Builds is an ambitious project that has both the client side deployment infrastructure as well as a full kind of Rails Engine implementation on the back end for implementing the server side piece of this. Ember CLI Deploy has the best name in my opinion, right? Kind of makes sense. That's what it is. That's what you would expect it to be named. And so the Ember Deploy has the biggest ecosystem out of these and it has about four well put together plugins to do different types of deployments. Deploying your HTML file to S3 instead of to Redis. The folks, a gentleman from Microsoft contributed an Azure component. And so, because of some good momentum around that. And so what we did just last week is we pulled together a conference call. We were able to pull it together in about 24 hours thanks to Twitter's new group DM functionality. And on that call, we decided to merge these three projects. So instead of three awesome projects, each with one or two maintainers, we now have one awesome project with a team of now six people because in addition to Michael Klein, Sam Selikoff, Ryan Toronto, and Aaron Chambers who were the maintainers of the projects I just described, somehow just as open source luck would have it, Dan Schultz has jumped in and been an enormous help. I don't even know how he found out that we were doing this stuff. So the team is tremendous and we're really excited about moving forward. And we've moved the project from Michael's domain, Michael's GitHub user underneath the Ember CLI umbrella thanks to help from Steph. And so we're really excited about making this a well polished, kind of well oiled machine that's going to be kind of the one stop shop for getting deployment set up for Ember apps. And this experience to me is what paving the cow paths is all about. It's going from an idea to a few different implementations where we're experimenting with concepts as far as how best to approach it to now kind of coalescing under one kind of Ember approach to the problem. So where are we going from here? The roadmap for the next release is 040. It's relatively a small step. It's making sure that the ecosystem that had grown up around Ember deploy gets moved over successfully to the new name and the new infrastructure. And this is pretty straightforward. We want to provide migration instructions for users of the old Ember CLI deploy. We're also deprecating JSON based configuration in favor of a JavaScript file so that you can easily consume environment variables for sensitive credentials and so forth. Timing for this is we're hoping to have this released by the end of this week. The roadmap for, awesome. The roadmap for 050 we're really excited about and we're looking for input on this too so you can visit the repo and look at the deployment pipeline issue and chime in. We're looking to move to what we call kind of a pipeline hooks and plugins architecture. And it's taking the plugin approach that currently was evolving around Ember deploy and moving it to be modeled really after the Ember add-on approach. And these plugins indeed will be Ember add-ons themselves. They'll get to leverage all the Ember CLI infrastructure that already exists there. We're gonna be adding a post deploy hook so that we can easily communicate to Slack or your IRC channel with each deploy. Some nice details, who did the deploy, what time happened, et cetera, et cetera. And we're looking to provide some great documentation for plugin developers so that this ecosystem can flourish and we'll be providing a lot of support to the people who are looking to add plugins here. And finally, Ember CLI front-end builds, which as I mentioned is one of the most ambitious kind of takes on this, is going to become a plugin for Ember CLI deploy. And so that's gonna really help us exercise our API early to make sure that we're arriving at the right ideas. And the basic architecture I kind of alluded to just now, Ember CLI deploy plugins will be Ember CLI add-ons with an additional keyword. They'll be auto-discovered, auto-wired up. You'll obviously need to provide some of your own configuration for to be able to successfully talk to these, the backend services involved in your deployment. The goal is that you'd be able to deploy from either your development environment or from your CI environment. So there'll be both some nice interactive tools to work within the command line as well as kind of silent, headless tools. And the plugin kind of hooks that these plugins can implement are listed here. We'll deploy, build, update assets, update index, activate and did deploy, as well as list, which lets you look at your most recent deployments and choose to activate a particular one, roll back to a particular one. So the basic usage pattern will look like this. You will have configured one or more deployment targets, be able to say Ember deploy staging. That will deploy your assets and your HTML to the configured staging deploy target based on the plugins that you've got in. You'll activate the release and notify your group chat. Made a mistake. You can use Ember deploy rollback staging, rollback to the most recently activated version, also send a notification. Want to consider what you should be releasing. Ember deploy list is going to give you a list of recently deployed things for that target. It's also hopefully for most plugins going to be able to give you a preview URL like I described earlier. So as a developer, you can grab that, take a look and have once kind of sanity check before you decide what version of your Ember app to activate. To actually perform the activation, you'll pass this identifier to Ember deploy activate. And that usage, what everything I just described is not something, some of it exists today in zero, three O and will exist in zero, four O. A lot of it is going to be changing somewhat for zero, five zero. So again, looking for input, those of you who have implemented deploy solutions yourselves and I know everybody in this room who has an app in production has done that. Talk to us about what you would love to see. Beyond zero, five, zero, we would like to support deployment to named buckets to support the kind of A, B tests and beta testing things we've talked about. I'm sure that you've used apps where they allow the end user to kind of toggle between classic and beta, right? So that you can get people starting to experience a new version without necessarily putting them at risk because it doesn't have all the features that your initial, your current version does. We would like to be able to support that scenario pretty cleanly. And then beyond, can tell you also beyond zero, five zero. I've talked to some folks where deploying the HTML is not a great fit for them. It makes more sense for them to have, let their servers continue to kind of render the overall HTML, but instead we want to be able to deploy configuration information. So what are the JavaScript assets? What are the CSS assets? What are the configuration options that I'm taking kind of from my static build and then letting me and the server merge them with the configuration options that my server is driving to be able to produce this page? Cool, somebody likes that one. And let's see, we just talked about this one. Did I miss one? No, that's the same slide, say Levy. So in addition, as I said, your use cases, your ideas come talk to us. To me, this experience over the last year and then in the last week has been really emblematic of what I love about this community. When we got on the conference call last Tuesday, we had five people on the call that most of whom didn't know each other, hadn't had a ton of conversations together because we have a common mindset from what we've learned by watching the Ember project evolve. We have a common set of tools that we've become good at using from Ember CLI to GitHub to Slack to IRC. We basically were able to make some decisions together that this merge was the right move and be productive as a team in literally a matter of minutes. It was a pretty astonishing thing and really kind of this paradigm, which I know a lot of you have experienced in open source already, is unparalleled in the history of humanity. So without getting too high fluting on it, it's pretty awesome stuff. So one last idea that I wanted to just throw out as stuff that we can talk about later. How does this work with Fastboot? And so I don't have all the answers to this. I've thought about it not too long, but one possibility is that in this scenario is that your Fastboot server could sit in front of your API server. It could be reading HTML from that API server, proxying API calls back and caching your JavaScript locally. And so there certainly is a simpler scenario for a Fastboot server, but if you wanna take advantage of all the possibilities that I described earlier, we may wanna consider having a relationship between our Fastboot server and our API server that's a little bit more robust. So anyway, this idea is something that I would really love to talk about at the party or later today with folks, so be thinking about it. And with that, this is attributed to Steve Jobs. I don't know if it's true, but real artist ship, real artist deploy, and thank you to everybody who's kind of helped make this particular journey possible. It's a small story and kind of the overall arc of the Ember story, but it's an exciting one and one that I feel really lucky to be a part of. So keep in touch, join the fun if you're interested in this stuff, and if not, just get ready to take advantage of a nice new convention for the community. Thanks.


So when applying L'Hopital's rule, it's important to remember L'Hopital's rule only replaces one limit with another limit. This means that all limit rules previously known remain in place. So I suppose f is continuous with continuous derivative at x equals 3 and our limit is x approaches 3 of f of x is 12 and our limit is x approaches 3 of f prime of x is 8. Let's find the limit of this composition. So we should always check those admission forms. As x goes to 3, our numerator goes to and our denominator goes to and since numerator and denominator both go to 0 as x goes to 3, we can enter the L'Hopital. So we'll differentiate numerator and differentiate denominator and let's take a look. As x goes to 3, our numerator goes to and our denominator goes to so we could apply L'Hopital's rule again but this would require finding the second derivative of f which we don't have. But we can always do some algebra and here the thing to notice is that the numerator has a factor of f prime of x and so does the denominator and we can simplify and numerator and denominator still go to 0 so we can apply L'Hopital's rule again and this time our denominator is not going to be 0 so we might be able to find the limit through direct computation or let's take a look at another limit. So again always check the admissions form and we can apply L'Hopital's rule. However we need an extended L'Hopital stay because our numerator goes to 0 and our denominator also goes to 0 and again differentiating again requires finding the second derivative which we don't have but remember all of our limit rules still apply and the useful one here is that provided the limit exists the limit of a product is the product of the limits and so we note that this thing that we're trying to find the limit of can be written as a product now since L'Hopital's works on indeterminance of the form 0 divided by 0 we might take a look at our numerator and split it into a part that's going to 0 and the leftovers and likewise our denominator will be a part that's going to 0 and the leftovers so we can rewrite this quotient and limits all around since the limit as x goes to 3 of g' of x isn't 0 we can find the second limit directly the other limit requires a return to the L'Hopital and again numerator and denominator are both going to 0 but we can split numerator and denominator into factors that go to 0 and everything else and again the second limit exists and we can find it directly and we can find the first limit by another L'Hopital visit and since g' of x isn't 0 we can evaluate this limit directly our numerator is going to be 0 and everything else is going to be some real number and so our limit is going to be the product of 0 times well it doesn't really matter what


to this paper of the presentation is the role of MRI study in evaluation of the perianal tissue line. My aims and objectives are to diagnose, evaluate perianal tissue line to determine its course extension relation to surrounding structure which aids in the pre-operative planning to study the age group gender-wise distribution, to determine the incidence of the recurrence and allowing the side effects as such like fecal incontinence to be avoided. Introduction. In a fissula there are abnormal collection between the two epithelial structures or organ or between an organ and the surface of the body. In perianal fissula abnormal collection exists between epithelial surface of analgenal perinium. MRI allows to identify the second defects or their disease extension to the perianal and supra-livator space that would be otherwise remain undetected. Perianal fissula can be primary or secondary to inflammatory bowel disease, constipation, malignancy or previous surgery etc. Discussion. Techniques for the imaging, techniques for the imaging perianal fissula on anal-steam and weighted images that provide an excellent anatomical overview of the sphincter complex, livator space, ischorectal fossa, fissula strike, inflammation, however, appear area of the dose in the intents and it cannot be distinguished from the normal structure, however T1 images are useful to discriminate between the post-operative hemorrhages from the residual track, from the residual track as the former will appear hyper-indent on non-enhanced T1 weighted images. On T2 and STER images, sphincter strike, inflammation, abscess appears as the area of hyper-indentity can be clearly distinguished from the normal tissue which appears hyper-indent.  Anatomy of the perianal muscle on MRI. Ischorectal, first of all, there is a, we have two images, first is the schematic diagram on your left and there is a MR T1 weighted images, XGL, it suggests external sphincter then inter, between external and inter, there is a inter sphincteric space, there is a ischioenal fossa, you can clearly see ischioenal fossa inter sphincteric space, inter and external sphincter.  There is a two classification, two classification to classify the perianal visual as according to the surgical treatment or interventional groups, first there is a inter sphincteric, trans sphincteric, suprasphincteric, extrasphincteric, external sphincteric is a keystone of the paraclassification, external sphincteric, mostly external sphincteric, once there is a trans sphincteric, you can see A is the inter sphincteric between internal sphincteric and external sphincteric, B is your trans sphincteric, E is your suprasphincteric and And D is your extra symmetry, which is extending up to the supra-liquidate space also. There is another classification, Sanjim's classification. Grade 1, grade 1 is a simple inter-synthetic specular. Grade 2 is inter-synthetic specular with absolute second ray track formation. Grade 3 is a simple trans-synthetic specular. Grade 4 is a trans-synthetic specular with absolute and secondary track formation. Grade 5 is your supra or extra-synthetic specular. Here is the inter-synthetic specular, T1 veterinary. You can clearly see which through the extra-synthetic and entering the inter-synthetic at peak proper operation. This is your trans-synthetic specular. You can clearly see an axial contrast at the T1 veterinary. Trans-synthetic specular, which is seen by error. And highly enhancing trans-synthetic specular from the dented line to the skin to an issue anal portion. NPRC to the root. There is a supra-synthetic specular. There is an extra-synthetic specular. A hyper-intensity track between perirectal and perianal from 1 o'clock to 6 o'clock. Communicating with the rectal canal at 6 o'clock position, track the same downwards to the left at an extra-synthetic force, abutting the levator and eye muscle. Grade 1 specular is a simple inter-synthetic specular. Grade 2 is an inter-synthetic specular with collection and excess formation. Simple trans-synthetic specular. Trans-synthetic specular with collection and excess formation. There is a supra, an extra-synthetic specular, which is also called as a supra-levator space. Extending into the supra-levator space. Materials. The source of the data in the patient is an STD ocular and Mdala. All the patients refer to the department of radiology and STD ocular in Mdala. We list clinical suspects or diagnosis of having perianal specular in period of July 2022, a detailed issue of regarding sex, age, sex, clinical and radiology. There are samples that this study conducted 40 clinical suspects or diagnosis of having Priscila in plain MRI studies. Age group. There is a diagnosis of having most of age group is 40 to 60 years of the age. There is a two classification and there is a path and samples and according to the most common studies is inter-synthetic Priscila and the most common grade in our study is grade 1, simple trans-inter-synthetic Priscila. The results. Out of 40 patients with clinical suspects or having the diagnosis of the perianal specular, 31 were male, 9 were female and this majority 27 belong and belongs to the 30 to 50 years of the age group. With the inter-synthetic being the most common, according to class 1 and grade 1, according to St. James conclusion, MRI has the ability today to detect Priscila associated with abscess, serine deformation, other challenging life for other radiologically modalities. In addition, there are, can provide the comprehensive images of anatomical correlation between the secondary and pelvic floor and liver tereporeal. Evaluation of clinically undetectable, significant bearing on guiding the medical therapy or surgical therapy, it can help in minimizing the recurrence and improve the pre-operative surgical planning and post-operative outcomes. This is the list of reference. Thank you so much.