Developer Tooling Community Meeting (April '22)

Captions as YouTube publishes them, usually machine-generated, so product and people names can be misheard.

1. 0:10

   hey everyone welcome uh to the first developer tool community update this is another weekly series that we're going to be doing uh pretty much every week if you haven't if you've been registering for all of these we're having a different topic so the third thursday of each month we're going to go over developer tooling what's coming up what's new and get your feedback live from it uh and also we'll post this up to youtube if you haven't seen we've

2. 0:34

   been uploading these to youtube about a day or so afterwards um so yeah feel free to watch these and um yeah register for the other webinars as they come out this week we're gonna be talking about workspaces um we're talking about russ sdk the new update uh and then yeah a little bit of a road map update and then q a we'll open it up at the end so at the at the bottom of the screen you

3. 0:58

   should see a q a question if you could ask your questions there um go ahead and post them if you want to come up on stage and ask a question live uh ping me in chat or just post a message in chat that you'd like to do that and we'll bring you up at the end of the presentation um so yeah without further ado do an introduction um austin b do you want to go ahead and introduce yourself yeah of course uh thanks for

4. 1:22

   thanks for having us and great to see everybody i'm austin baggio and i'm uh the product manager for the dev tools team uh yeah and and i'm just gonna reiterate what josh said today we're really excited to just share a little bit of a deeper dive into the sdk 4.0 uh workspaces rs and then we'll talk about what we're going to focus on uh for this quarter and share a bit of our roadmap so

5. 1:45

   um i'm also i'm joined with by austin and fong um i'll i'll pass over to you austin if you want to introduce yourself yeah sure uh i'm austin the uh awesome a i guess uh austin able um so i'm i'm the team lead of the court of the developer tools team so i'm basically focusing on like the rust tooling so uh we should center around the rust sdk and stuff like that um and with me i work with you know font danielle miraculous and and fong is uh i'll let fong introduce himself

6. 2:17

   all right for sure i'm fong i'm a developer on the developer tools team and i'm mainly focused on rust tooling i mean rust testing and tooling but uh mainly on workspaces and a bunch of some other stuff too but yeah mainly workspaces for now cool sweet um let's let's jump in let's start talking about the sdk uh austin i think you want to share the discussion yeah yeah so we'll share my screen

7. 2:50

   you can see my screen there no right yeah sweet so hopefully hopefully this strong font is big enough if it isn't someone bark at me hopefully uh that that should be that should be big enough to kind of read everything um so yeah just give kind of a high level overview of um what we'll be talking about today so this is a lot of changes that have happened over a long period of time uh but since this is the first time we are doing a community meeting there is somewhat of a lot to

8. 3:14

   cover so what i've tried to do is try to like consent to condense it down into the things that are gonna change for like when you're actually building a contract like what will functionally change for you and i won't go too in depth with like actually the lower level optimizations or anything like that um so the the first main initiative that has that has been going on with the

9. 3:37

   update to the 4.0 sdk is the uh collections update so if you're not familiar with collections these are basically just like data structures but their the state of it is actually like sharded and persisted onto you know the near blockchain and then and this just allows it to be more scalable um but what we're changing is that we're moving these collections and like basically iterating on them to create like a version two of these which are

10. 4:01

    going to live under uh the near sdk store module um the reason we're kind of putting in a separate space is because we want it to be an easy transition from the from the old collections but also we want to make it clear that these are actually like storing data on the blockchain and not just in memory data structures um so how you can access these new data structures right now is if you're using any of the 4.0 pre-releases you just

11. 4:25

    have to enable the unstable feature flag um this is just going to be unstable because there might be some like format changes until until this is actually released um but anyone can actually play around and use these most of them should stay stable but this is just kind of so that we don't have like uh some bear breaking changes um so the plan for the migration is just that these will be stabilized soon and then the existing ones that exist under

12. 4:49

    near sdk collections will be uh moved under a legacy feature flag but they will always be available so that if people want to continue using um the existing collections they have that's that's totally fine um so kind of the reasons or the motivations for for creating these like version two of all these collections um the first one would be having a caching layer so that um there there isn't any redundant reads or writes right now if you're modifying a certain key value pair or any sort of

13. 5:19

    like element in these data structures everything will be written as many times as you actually call out into it um so this basically removes all that redundancy so that all all loads from storage are like kept in this caching layer and like lazily loaded and then any changes you make are persisted at the end rather than every time you do a specific operation um so this will kind of like optimize uh gas usage for

14. 5:44

    or certain contracts um not all of course but uh the next point of of like why we're doing these changes is that um it's it's a lot less error so these apis are gonna much more closely match the rust standard collections apis um so it's gonna be much more like idiomatic rust and be able to like hook into a lot of the like powerful rust you know compiler features to be able to make sure there's

15. 6:10

    there's no like data inconsistencies or like you know data races or any sort of or any sort of like bugs like that um and then also it allows us to do a lot of uh added additional apis that didn't previously exist so things like the entry api if you're familiar with like the rust hash map entry api it's like a very convenient way to be able to um get an entry and like insert if if there

16. 6:33

    isn't actually a value or modify if if there already is so it just creates these like additional patterns that that weren't possibly for and then also allowed to like immutably iterate over a data structure rather than having to do everything manually yourself so to give an idea of like what a pattern that's kind of like a a little bit of a foot gun that that is exists with the current collections is when you're actually trying to modify

17. 6:56

    value actually you have to like load it into memory you have to modify it and then you have to insert it back and that's kind of like a disruptive pattern for developers because it's much more error prone because you actually have to like make sure that you're manually inserting it back and doing so in the correct way um so like here's kind of an example of what you would have had to do before which is you know loading the value into memory modifying it and then inserting

18. 7:20

    it back where with these new data with these new collections you're able to like actually modify the values in place and it'll do everything else you know for you so that you can you know just write the code you need and not have to worry about you know making sure all the logic connects all correctly um and this has been kind of a pain point there's been you know bugs opened with this being misused currently so this will kind of eliminate so many different bugs that make it so much easier for

19. 7:44

    people to just do what they want and have a drop in replacement for uh the rust standard elections um this obviously there's no free lunch like there will be downsides to this and and one of those is just that there is a little bit of overhead with this caching layer um so there might be like a you know a slight coat size increase for people that are using this stuff uh another thing to keep in mind is that the the near contract standards are still going to be

20. 8:08

    using the old collections for now there is a plan to migrate this over in the future uh but for now that is the case um and then also using this more idiomatic rest api is is gonna be very familiar for people that are used to writing roughs but if you're not used to writing rust this might actually be a little bit of a hurdle to get over at first just get used to how how this pattern works and get used to

21. 8:30

    this new api um but hopefully we'll be able to you know provide any documentation on how to like switch switch over between the two or you know help anyone on this on this transition over um and then also another another key point to mention is that some of these collections aren't actually backwards compatible on a storage level because some were kind of modified in such a way that you can't just like drop and replace the old collection with the new one because there was a lot of like

22. 8:53

    optimizations uh from the you know reading and writing to storage uh that it made sense for these not to be backwards compatible um yeah so so the next point the next kind of initiative that we're kind of focusing on is is better air handling so within the sdk there's a lot of patterns around you know unwrapping or panicking with with air values and this is kind of it's a little bit unintuitive for people that you know come from

23. 9:19

    writing other types of rust programs where you're used to having like result handling and like not have to unwrap or do all this extra code for for certain operations um so the first the first support that we're adding with this is you know being able to return results at the you know at the function level so um now when you whenever you right now we're going to have this like temporary

24. 9:42

    annotation called handle result um and this is going to allow you to like put a result as a return and basically what this is gonna like is it's gonna create the glue code so that if this does return an error it's basically gonna panic with that error um and if and if it is okay with whatever value is in the okay type it's basically gonna serialize that and return it as the result as it normally would be before um and

25. 10:07

    this doesn't come at any like any cost like this is basically um going to be optimized away by the compiler the this level of complexity um because you can do anything that implements as ref string um and basically just print out that error or like panic with that error uh so it doesn't have like this overhead of having to use formatting machinery but if you did want a more complex type that did use formatting machinery you

26. 10:31

    can do that so this in this uh in this discussion post that you'll have a link to um you can see like there's a more complicated example where you know you have an actual structured error type which has you know is going through formatting machinery and you can still use that so it's like very extensible but also at the same time uh it can be just as efficient as doing uh operations as you would before

27. 10:55

    um so yeah i kind of mentioned that uh yeah it just just to be clear like this is just like a temporary annotation in the future we will remove this um the reason we're keeping this for now is just because um we want to make sure we're not silently breaking contracts that are returning a serialized result which is kind of a different thing where it's basically uh saying that this contract succeeded but we're gonna uh you know serialize whatever the result type is

28. 11:20

    which is kind of a different pattern um but then obviously in the in the next release like the 5.0 release this this annotation will be removed and you can just do error handling how you normally would um and the second parts of their handling that we're kind of improving is the callback handling so callbacks are common if you haven't worked built a you know a rust contract before and haven't used callbacks um they are somewhat um important for doing asynchronous calls and like

29. 11:51

    getting back a return result and completing with it um but currently the the pattern was that whenever you're using this callback uh annotation it's going to unwrap if there is any error and basically panic immediately and that's not always like a great pattern for developers because sometimes you actually want to like gracefully handle that error and do some logic specifically if it did fail um and this

30. 12:16

    basically allows you to like have result types that you don't have to you know manually check if certain promises fail they're succeeded uh which will make just your code a lot more easily easily written like read and then also just allow you to do certain patterns that you weren't able to do before um some other small stuff so if you try to migrate from version three to version four you might see that like

31. 12:39

    the the one change that might be the most breaking is just that uh account id is now validated by default um so before account id was an alias to a string and then there was this another other type called valid account id which would do all the validation for you and whenever you're using this type in a contract you kind of have to think which type is which and you know either unwrapped from a valid account id to an account id to

32. 13:02

    be able to interact with things and it was kind of a very confusing pattern um so for now everything within the internal sdk apis are now going to be like just one type the account id and it's going to be validated by default but if you want to skip this validation and just have the contract just as optimized as it was before uh you can use this like account id new unchecked method um there's a lot of documentation on like what the differences are uh

33. 13:25

    between the two or like how you migrate between them and hopefully all the examples within the sdk and otherwise are gonna make the transition simple but that's basically a tldr of that change um there's also no need to use the the setup alec which was a thing that was a previous artifact of version three which um basically set up the custom allocator to be more optimized for for a wasm smart contract um this is now just like

34. 13:51

    enabled by default and if you did want to opt out of it you can just like disable that feature um and one other thing this is probably something that most people don't interact with but if you're interacting with contracts on a very low level um there was kind of this weird pattern where you would have to go through this blockchain interface to be able to perform these low level operations and

35. 14:15

    interact with the syscalls directly um you wouldn't necessarily have to but this was kind of the the uh the pattern given in examples and was followed by a few contracts that were writing low low-level contracts um but now if you ever did want to like transition from this it's as simple as just uh calling the methods directly from uh near sdk uh the sys module um so yeah the code will be a lot simpler if you're trying to write low level contracts um and yeah that's that's this obviously isn't pattern that most

36. 14:47

    people are gonna use so i won't go too much in detail about that um the next point which is kind of an initiative that's that's more current like this is something that's happening right now um is there's a nep 264 protocol change uh which is going to affect the sdk apis with regards to cross contract calls so there's a bunch of links in here like if you follow them you can see all the information about like what at a low level the the actual protocol change

37. 15:13

    will look like um but essentially it's just adding another host function that allows utilizing the unspent gas from the current transaction and this might seem like a very simple thing but this actually allows a lot of a lot of patterns and allows us to simplify our apis for calling cross-contract calls because the current pattern is right now is you have to like specify a very a static and specific amount of gas for each asynchronous call you make um and

38. 15:38

    this basically allows you to like split the amount of unused gas dynamically which will make contracts uh across contract calls uh much less like uh much less error prone and just like much more ergonomic and code much more readable so um that's kind of the the initiative there um there's links to like the prs and the discussion and everything if you want to dig deep into like what this actually looks like um and like what the

39. 16:01

    changes would be like from the current cross contract api to the new one um there'll be more documentation once this fully finalizes there is a pr with the implementation and all of the details as it is right now but that isn't you know completely final so i won't go too in depth with like uh what this will look like um um uh before we move on let's just um take a quick pause just to kind of cover

40. 16:24

    the um we have a few questions from somebody yeah yeah earlier let's do that before we dive in dive into more stuff no it's all good but yeah absolutely absolutely um yeah um till asks is are there uh the state breaking updates um are the state breaking updates state breaking from v3 collections or does this affect the 4.0.0 pre-seven collections yeah so so if you're if you're upgrading from version three to version four there's no there's no breaking changes that you have to worry about as far as like the collections the only difference

41. 16:57

    is if you're switching from the the collections under near sdk collections the ones under your sdk store because they're like completely different structures and it has to be very intentional for you to switch which is kind of intention which is you know intentional by default so that if you are doing this you have to like think about the breaking changes and most of the time it's dropping and replace but um if you're just upgrading from version three to version four you don't have to worry about anything being uh breaking

42. 17:22

    like you can just upgrade your contract and uh nothing should be nothing should be state breaking if there is anything that's state breaking then open up an issue like that's definitely not intended awesome that answers that question thanks um next question is how will the new caching feature affect gas fees for performance yeah so so there is a slight overhead um it really depends on the usage um that's

43. 17:45

    why it's hard for me to give like exact numbers because it really depends on how you're using these collections to be able to give an estimate about what that overhead looks like um it will save gas if there is a lot of overlap on the on basically the values that you're indexing like say if you're practicing a key a couple times uh you're gonna save gas but if you access all unique values

44. 18:08

    um there will be a slight overhead but that overhead grows if there's a ton of values you you you access so there's a lot of complicated like different cases that you could consider um if you have if you're curious about maybe like a specific one like a specific use case or like you have some code i'm like i'm happy to just like look it over and give a suggestion on like what the differences will be um but

45. 18:30

    yeah it's really hard to give like exact like you know figures of like oh there's you know five percent overhead or or you know it's it'll decrease gas cost by this percentage because it really depends on the usage um got it sorry for not being able to give like a very specific answer to that but hopefully that's helpful cool no no worries awesome and then yeah just a couple shout outs uh uh june's excited about the that they can use the proper account id rather than a string using in vm

46. 18:55

    context um super excited about that and then also yeah a few plus ones for the better and error handling and callbacks i'll also add a plus one to that i'm really excited there's gonna be better handling um there as well um cool yeah and again keep keep throwing the questions in the q a button at the bottom um we'll we'll keep answering them as they come uh as as far as the gas or the protocol the

47. 19:18

    the nap264 there was one question on that um and it said so the gas on the new cross contract call will now be automatically allocated uh as in no more static setting of the gas amount oh yeah so let me let me get more in detail with that because i i really should have covered that is um there's no you know flexibility loss like you can still specify a static amount of gas um and you can configure the amount of

48. 19:42

    like basically the amount of the weight of how much unused gas you're going to be allocating to each contract um but by default essentially each like the api right now that was proposed is essentially going to attach a weight of one to all of the all the different function calls um with zero static gas um so it'll just split everything evenly by default um and then if you do want to configure and like add

49. 20:05

    a static amount to each or just even remove the weight so you say you don't want to include extra gas on the specific operations um there's no flexibility loss like this is purely just like a a value add like you don't have to hook into this pattern like you can avoid it if you want it'll just be a simpler api and then you'll have this ability to just like not have to think about gas if you have a very simple use case or if you if you want to utilize gas more efficiently

50. 20:30

    hopefully that answers that question yeah awesome thank you um so yeah just to kind of tie things in um the 4.0 stable release plan i know this is like obviously a very you know delayed thing it's something that i've wanted to get the stable out earlier but we the the idea was to have this improved cross-contract api um in with this stable release so that's kind of we have to wait for the critical change to come through uh so that the the that implementation within your core has been released

51. 21:01

    and it has been deployed to test that um but we won't be able to stabilize the sdk until uh it gets released on mainnet which is in a month so um in that month the escape will release but people can play around with these apis before and like use it on testnet but because it doesn't work on mainnet we can't necessarily release it or else people's you know contracts will just won't work on maintenance um

52. 21:24

    so yeah if people are if you want to start playing with this on testnet um that's totally that's totally a possibility um so yeah that's the plan and then there's a tracking issue for the 4.0 release if anyone's curious when that's gonna happen like you just follow that issue um and it'll be updated once once that happens um one follow-up question about the cash cashing uh it says you mentioned the

53. 21:49

    cashing save gas if a key is get multiple times is this detected during compile time example cleverly don't cache if it knows it needs it only once and then cache it otherwise during compile time as things that are repeated will be known yeah that's not the case because the thing is you actually need that cash to get the the same api like for example when you're doing a get you're gonna be um you're gonna be getting a reference to the value um and to be able to get a

54. 22:20

    reference to that value you actually need that the the value to be put in the cache and then you're you're out you're getting a reference to it this might be getting too technical but like um you act but basically the the short answer is like we can't just like cache um only if it's being ad access more than once um and not only if it's being accessed once because the api is fundamentally different if if that's the case um so yeah it's just an initiative to to make

55. 22:46

    sure that you know there's no it's way less error-prone um cool awesome thank you i think that answers our question yeah yeah feel free again uh feel free anybody to follow up with more questions keep dropping them in and we'll keep answering as we go uh but yeah yeah if it doesn't answer i'm happy to follow up with that and give more detail um so yeah if there's no other you know questions right now or for now i'll just keep moving on to the to the next kind of shorter section but this is more uh

56. 23:12

    stuff that we're focusing on right now or something more for the future and early on is um what we're calling er this is this name is very much open to be changing in the future but is what we're calling right now an aci which is like our take on on on an avi which is basically like an application contract interface and what it's intended to be is uh like a human readable schema so

57. 23:35

    when someone writes a contract you can actually have this schema to be able to see how to interface with it and this kind of provides a lot of flexibility because not only does it allow people to easily see how to interact with contracts but you can also generate clients based on this and be able to at compile time connect any sort of front-end script or even another contract through cross-contract calls at compile time which is kind of like very powerful to

58. 23:59

    be able to like eliminate a bunch of like redundant duplicate code of having to like define the interface on the front end and on the like you know on the contract and on the front end and make sure they're you know connected correctly that's especially difficult when you're doing it in different languages um so this is kind of the initiative that we're working on right now um it's you know going to be very it's going to be similar in ways to the solidity avi if you're familiar for

59. 24:24

    coming from the ethereum space um and but it's obviously going to have its differences because you know near has differences in its protocol and stuff like that um there is kind of like an example of what this somewhat will look like but obviously not final uh just to give an idea of like what the format will look like because it's going to have some data about which methods are exposed what the details about those methods are um and any details around like the

60. 24:49

    serialization format of any parameters or results so yeah i won't go too much in detail about this because uh around the specific format because um that is like subject to change like it is something we're iterating on and making sure we're doing it correctly so um if you do have any opinions about what this you know what should be included in the schema or um anything that you think is off like please feel free to like either share in

61. 25:12

    this discussion or there will be one made specifically for the aci in the future um and we'd love your input it's basically what i'm trying to say here um so so basically the part parts the three kind of components of like this initiative is one deciding on a schema format that is kind of accessible for everyone and you know intuitive for people to use um and then the first part of that is like we want to be able to generate the schema from the sdks that

62. 25:37

    people don't have to like manually define us or anything it's basically you write your contract and then you'll be able to emit this schema you know file or you know idl or whatever it is uh in json format and then uh the third part is just like being able to generate a client from this so being able to like generate the glue code to be able to like interact with this through a client library or through rpc or you know through a cross-contract call um

63. 26:02

    so that's kind of the initiative like obviously i'm not going too much in detail with this because it's very early stages um but if you do want to follow like the kind of proof of concept um you can see the work that daniel has been doing on his branch it's all linked in the in the discussion here um but yeah once it's more like you know fully connected and usable we will kind of share that with the community and

64. 26:24

    hopefully get as much input as possible um and yeah that's that's pretty much all i wanted to cover i don't know if there's any like final questions i might kind of scan through this before i pass it off to fong um yeah just one question about uh with the aci asking about if there will be some sort of implementation of this and explorer uh might be a little yeah soon to um have an answer on that but

65. 26:47

    but yeah yeah so likely it's it's maybe possible um it's it's not exactly so so the difference is why it probably won't be on the explorer is because um this schema won't actually exist on chain this is a purely off-chain like tooling thing to be able to interact with um you are like maybe there is some way like we can allow to be able to like upload schemas or something like that to

66. 27:11

    the explorers so people can see like what the contract interface looks like um definitely possible and will give you a lot better diagnostics um and there's so much flexibility with what you can do in front ends to be able to like see which what contract or how to interact with the contracts and be able to like easily you know call out into them and perform transactions on them um so explorer is definitely possible but more so with with other tooling such as

67. 27:36

    just like any sort of front end maybe even the wallet like if you're trying to like interact with certain contracts i'm not really sure i mean there's tons of tons of different options but um yeah hope hopefully hopefully that gives somewhat of an answer to that question cool um yeah well without further ado yeah i was going to say yeah uh pass over to fong unless uh there's anything else you'd like to cover no that's that's that's pretty much uh how that will what i want to cover uh

68. 28:06

    cool awesome yeah and keep dropping those questions um after fong does his presentation uh we'll open it up for kind of an ama on anything um so keep dropping questions in the q a section at the bottom of your screen all right sweet so thanks austin for that update um let's continue on to workspaces see let me share this desktop okay can anyone see the discussion notes here yep

69. 28:39

    sweets so um i'll be discussing workspaces today if uh you don't know what that is uh going forward workspaces will be um replacing sim uh sdk tests and uh those will be deprecated and workspaces will be the the one go-to stop for that now since uh it has a lot of nice niceties and improvements over them like uh being able to benchmark and get accurate uh gas usage from uh calling into contracts themselves while

70. 29:11

    testing um but yeah so like today i'm just going to be discussing what's changed in workspaces 0.2 so we've added a couple new features like time travel so you can advance to a future state in the your local testing environment so this will be if your contract relies on anything time sensitive or anything related to like block heights or epoch heights um you can basically just advance into the future and be able to test that

71. 29:44

    really easily that's without like having to wait for the actual blocks to be produced themselves which is pretty nice in my opinion um traveling it's awesome and uh i'll show this a little bit more and later on in a live demo of uh of testing this with a crown cat a scheduling contract some other noteworthy features is uh compiling your projects on the fly while testing you can specify a path to your contracts uh project basically so like

72. 30:23

    if it's uh you have a cargo.tomo and uh you define like your smart contract in a specific folder you use uh target there and it'll compile it for you give you back the walls and you can deploy it right then and there on in the test itself um some other uh changes that happened were some breaking api changes such as needing weights before uh spinning up a sandbox but most of them are pretty much convenience changes so um if you want to see what that is like

73. 30:56

    please take a look at the changelog in workspaces rs workspaces is really new so a lot of feedback is uh definitely needed and appreciated if uh if you guys can go take a look at that uh see where we can improve uh there's definitely a good amount of cruft that uh i haven't seen that that still needs to be spotted for sure but yeah it's uh definitely new and uh it's whatever you guys want to see out of it uh i just know there's some

74. 31:29

    features that are really nice to have but maybe i don't know all of them so please leave any feedback and without further ado let me go to the demo itself um okay can i see it in my code editor yeah yeah we can see it sweet so this is uh let me before i go explain what the code does let me run it um just so you guys can see the output and this is the uh the cronkite example itself you guys will be able to see this on the

75. 32:03

    repo if you want to follow more in-depth i i've left a couple comments uh this should be in later this week but yeah as that's running let's uh let me explain what what's happening in here so uh first off let's just uh first off get some of the concrat contracts inside uh the concat repo you can find that over here if you follow this example and that contract will be the manager to schedule your task

76. 32:36

    and run specific uh yeah basically around specific tasks in the future or any in a specific time um but yeah so this is what it would normally look like for this specific example we start with uh spinning up a sandbox and with this uh worker that we grab from the sandbox uh being spun up we can use it to deploy contracts and then uh call into them so there's a specific counter contract

77. 33:08

    i'm going to be deploying as well which is just to increment decrements by one it's um you can find out on the near near examples website and that's like the most basic contract you can get with just like incremented decrementing um i'm also going to be deploying the manager contract itself which will be scheduling all the tasks later on um then afterwards we're gonna be creating or we're gonna be scheduling

78. 33:40

    the task itself every hour with this specific call right here and this is just cronkite specific notation for um for cron syntax and that would be just for every hour so yeah and then we'll have to just an agent to be able to run that specific task then we'll actually like try to actually run it so uh this is just a lot of boilerplate from like crown cat itself just trying to register the the agent and stuff you can just uh look through chromecast

79. 34:14

    documentation if you want to learn more about that but this is the juicy bit where i wanted it where i wanted to really show so after an agent has been registered to execute the task we're going to fast forward about an hour into the future or 4 500 blocks and this will allow us to test whether this task has been scheduled and has been executed or not so then we'll we'll try to execute the task

80. 34:47

    given the conditions on the contract that an hour has passed and we can actually like see if the task has been ran or not and after all that it's said and done we should be able to see that the task has been ran and we get like rewards for executing that task from our agent and uh yeah and we should see like the amount profited after executing the task itself and it should be done by now let's see my outputs yeah so yeah the the agent profited like this amount of yakuto near from

81. 35:20

    executing that specific task we scheduled and all this is using time travel and we don't have so like before you would actually have to wait an hour to execute this whole entire test but now we're fast forwarding you only probably wait like a minute or so and yeah yeah let me know if um if you guys have any questions on any of this but otherwise i can just pass it on to uh austin baggio with the road map cool yeah no um i don't see any questions yet but yeah if anybody has

82. 35:56

    any please drop them in um if you could basically oh yeah um i was actually just about to ask that someone just posted this question about workspaces js having a similar interface maybe we could talk a little bit about the differences between workspaces rs versus workspaces js sure yeah um let's see so workspaces js is basically the js counterpart to the rs version its api slightly differs a little bit

83. 36:27

    because it's been out of date for a bit um but it's being uh picked up now and uh uh you should see like a release in the next month or two with like uh newer api changes and like catching up to what rs has with time traveling um but yeah mostly js the js side of things is for front end if you want to use it for any kind of front end you want to test on the rs one is mainly for if you want to want to have like a rust contract and

84. 36:56

    test everything end to end on rust and have those guarantees all be there but uh for the most part the feature set should be roughly the same uh between the two it's just that each one will have their own set of conveniences like with different convenience functions and whatnot but um they're very similar um like that yeah just testing it out and like like uh the expect the behavior under the hood is all very similar it's just

85. 37:27

    spinning up a sandbox node where you can interact through it via a worker and uh be able to call into contracts deploy them like usual but yeah that's pretty much just what they're like between the two so it's almost like a one-to-one like this is just different languages but you'd prefer you would suggest individuals use workspaces js when they're trying to um test like near api js functionality with their contracts versus workspaces rs is not really for

86. 37:57

    that it's more like digging deeper into rough smart contracts is that correct yes so there are things that rust cannot do or rust can do that js can't and vice versa maybe it might actually be a good idea for us to kind of like not during this call but um as we have this tools list and our documentation kind of go over maybe like a check mark box of like this is the the features like they they both can do this

87. 38:22

    but js is is more for this and and rs is more more helpful for that but is there anything like on the top of mind that you could um yeah no yeah specifically just that like i mean like just rust yeah rust for the rest workspaces for rust contracts and uh likewise for javascript gotcha typescript yeah i think i think it's important to also keep in mind that they're very interchangeable like you can test a job you know assembly script or javascript contract with the rest

88. 38:53

    workspaces and you could do vice versa if you wanted i mean some people might want to write a ros contract and test it in javascript because their front end might be you know in a javascript front end so it's really just whatever people's preference is but once compiled to wasm it like it doesn't really matter what you're using it's just testing the wasm file at that point right yeah there's no connection between between the um like whatever sdk you use

89. 39:18

    and whatever workspaces it's just that's right i gotcha uh oh one slight remark uh it might be a little bit different for the javascript sdk that's coming but those will be highlighted when it comes out yeah cool cool cool so they're just pretty much almost similar tools but um just depending on what language you're more comfortable working with right cool awesome um someone asked also does this mean that jest simulator sandbox and local testing are going to

90. 39:48

    be deprecated um as you uh indicated this actually works with sandbox so that's kind of like the playground um that you're or i guess maybe i'll let you answer this question as well so um my local tests do you mean like the unit tests in in the sdk itself because those will still be there in some form but not but like if you use like a net simulator in sdk that will be deprecated yeah this is all for like simulation like any

91. 40:20

    you're trying to simulate activity on the blockchain that's what these testing frameworks are for yeah so yeah it will be completely replacing that and well it's not really simulating anymore so it's more like it's almost an accurate representation of what would happen on the blockchain itself just it's it's literally just a a node on the blockchain but disconnected from the rest of the network cool awesome that's a good good way to work just in just getting super specific

92. 40:52

    on that like sandbox obviously it's designed to simulate um like a real environment that's that's why we have it and that's why it's going to be a much better uh tool to use in the future um and just being like really clear with with sim tests like yes it will be deprecated we'll be providing migration like playbooks um like really good documentation really good examples um and and of course we'd love feedback for anyone that is planning on going through

93. 41:15

    the i'll just call like the sim tesla workspaces migration um we would love feedback so that we can make sure that uh like you have everything you need all the tools to to do that yeah exactly and the deveral team is going to be working on deprecating uh some tests from the examples that we currently have and then showing how to use these new frameworks on there as well so um yeah definitely and again please leave us feedback any questions

94. 41:40

    issues comments concerns but yeah you definitely are going to love it more than simulation simulation tests because i know a lot of developers have had some issues running those um but yeah uh just tests will still be you can still run those with your contracts and um yeah same like local tests in in your rust uh smart contracts will still be there but yeah this is more like you and then using sandbox so sandbox not going

95. 42:03

    anywhere we're actually using it it's just a framework built on top of it um someone asked can we estimate gas consumption workspaces rs i believe that is a feature here that's kind of one of the one of the awesome things that we have is like a gas profile oh maybe we can elaborate on that i would say a yes we can estimate gas consumption but b i remember there was some sort of tool that we were working on which is like a profiler and actually was telling you how much gas you're using to like spin

96. 42:28

    up the vm and and do all these like kind of breaking it down is that in workspaces or is that going to be in workspaces um that part i'm not so sure of but like if you want to estimate gas itself like you can do it per transaction um like right in workspaces like whenever you create a transaction and submit it to the network uh you'll get back your gas your gas burned for it and you should be able to accumulate all that yourself and see how much gas

97. 42:59

    is being consumed for your whole entire automation script or testing workflow awesome the breakdown was something within near core um it was something that was considered being exposed to network spaces but that's that's not like immediately available but it possibly could be something in the future cool cool and then as far as like estimating cross-contract call gas is that something that workspaces will be able to do so i'll know in my

98. 43:23

    cross-contract for my promised chain i can know exactly how much gas each cross contract calls using yes like um like at the top level you'll get the aggregate aggregate of all the cross-contract calls but uh for each of the receipts or each of the cross-contract calls you should be able to get the gas burnt as well for each of them beautiful yeah no that's super that's super awesome cool um

99. 43:49

    okay a couple more questions will there be an npm rust package to be able to pull this in as a version control dependency uh that is not in the plans right now but could be uh please amend a ticket and i'll take a look at that awesome cool cool for workspaces js is the environment setup um new for every test or only once i have six tests that take about five minutes um so it depends on what kind of functions in the javascript side you're using

100. 44:23

     so there is an optimization feature where you can call fork which copies the state of the sandbox and spins up a new one while not having to reunite initialize anything and that's like the fastest way to go about it but if you're purely just calling into let's say a net every single time then it will spin up a sandbox every single time and have to reinitialize everything cool let me know yeah go ahead go ahead oh sorry i was just i was just gonna yeah i don't know

101. 44:56

     if you were completely done with that question but i was just gonna jump back to the previous one i think i think when they're referring to uh being able to pull this in as a virgin control dependency i think they were talking about workspaces maybe not sandbox um in which case there yeah there is for there is like yeah it is deployed it is on crates i o so you can pull workspaces

102. 45:11

     itself i don't know maybe i'm just understanding the question that they asked and maybe we can get a clarification but yeah both these are able to be pulled in through through through whatever build system you know npm and crazy yeah if it's purely sandbox then yeah there's npm uh package for it already if you're trying to use the rust workspaces in npm that'd be a little bit different but yeah if you if that's the case please

103. 45:37

     submit the issue and i'll have to take a look at it um cool uh yeah please please uh ask any more questions cool cool cool um where can i watch this video again on our youtube so youtube forward slash near protocol it will be uploaded tomorrow or by tomorrow um yes you can watch this video again on youtube thanks for asking that question um june asks what does it mean by agent

104. 46:03

     profited in the output at the end of your test all right so um it's a little bit yeah so there's agent is like a thing inside cronkite itself an agent um executes the task that gets scheduled on the concrete contract and agents don't really work for free so once an agent executes a task it um it gets a reward so therefore like the profit is basically the reward they get from executing the task itself that makes any sense yeah yeah yeah awesome um not at all related but since

105. 46:42

     someone mentioned node npm are you guys using dev futures or considering moving to deno i do not know because i i don't work on the javascript side of things that that would be best um left for bo or sir he but you can uh ask that in an issue on the workspaces js for repo yeah absolutely yeah yeah any yeah any of these um yeah again the discussions that were shared earlier by both austin and fong will be on the individual repos

106. 47:14

     you go to github discussions and then inside there we're having a live conversation about um these future features releases uh any kind of feedback that you want to give us would be awesome and then yeah next month on this tooling um uh webinar we will hopefully have some of the javascript guys on board talk about new api js workspaces js i don't know maybe get an update on the javascript sdk which i'm really excited

107. 47:39

     about as well so um yeah feel free to come back next month in the tooling tooling meeting and ask some more of those questions hopefully we'll have those individuals on the panel um cool yeah i think i can pass this off now it's uh to austin b yeah that's a that's a perfect segue in in a month we're hoping to be able to talk about the javascript uh sdk um can you guys see that slide there um i'm i'm just gonna go uh i'm just gonna go over at a high level like like austin fong just talked in amazing detail about

108. 48:11

     some of the stuff that's really top of mind for us so this is gonna be a little bit repetitive but i just wanted to drill a little bit deeper into what we're gonna focus on over the next quarter and share the road map so um the first one is make near the most successful blockchain for web 2 developers um javascript sdk javascript workspaces this is obviously going to be huge and will help us onboard a ton of uh new developers second we've got streamline and improved

109. 48:34

     developer experience for creating full stack apps i'll dig into that a little bit more and then another one is just like from like a like pagoda perspective we just want to get better at making product decisions a lot of it is about getting feedback from the community um and we just want to do that better so um doing a little bit of a deeper dive into each of these um making near the most successful blockchain for web 2 developers javascript sdk workspaces uh workspaces

110. 48:59

     js um where you're like we're actively working on it both here are on it right now um we're hoping to to have that launch this quarter um and and just unlocking an entire new set of developers that are more comfortable in javascript uh writing contracts so um and and just hand in hand with that comes with not just releasing uh the uh releasing the the repos or or updating the repos it's just it's like updating readme documentation examples creating tutorials and all that so expect that to come and keep us honest for for how we

111. 49:30

     can make it as easy as possible for everyone to get started um streamlined and improved developer experience for creating full stack apps um austin already talked about the aci api slash metadata slash whatever we eventually call it um we'll we'll settle on a name um uh yeah and in fong obviously just talked about pushing workspaces as our primary uh uh our primary testing framework which comes with with decorating sim tests and making sure that that's a really easy process um another another item that we will

112. 50:01

     we'll likely talk about in the future is just getting feedback on project initialization so our goal for this quarter is to create a spec around how we should think about project initialization in the future we're not going to promise that we're going to have that done in the next couple of months but um we obviously need community feedback in that area we know that there's some some pain around like project initialization like creating your app um uh like the cli and things like that so

113. 50:26

     um a focus for us um and then the one that i i didn't mention there was was m1 support um we we just want to have that one support um should be able to install a simply script or um test with the sandbox using an m1 device so uh we'll be working on that um yeah and then and then finally the like making better product decisions getting feedback like one of the things we want to do is more sessions like this we're

114. 50:51

     gonna hopefully run three over the next quarter um and uh we're gonna improve our project management tooling which hopefully just increases transparency and just gives us a feedback tool uh for uh our feedback mechanism to to get feedback from the community back to the development team um and then the final one is just like we just want to make sure that we're evaluating all of the other ecosystems so we're going to give

115. 51:13

     like our team some some time to explore other ecosystems other solutions that are adjacent to the products we're working on if you have any suggestions or have any ideas um uh please just reach out or uh add to the discussion for for stuff you'd love to see uh cs building um and then that's that's a segue into the roadmap um the reason why i'm sharing this is just to reiterate our focus but also to say what's not on here um what

116. 51:39

     did you like in the community expect to see on this roadmap from the dev tools team so um i'm not going to go into d we've already talked about all these so um but yeah rust sdk getting that launched uh javascript sdk and workspace there javascript sdk and workspaces js so i should say js on sdk um delivering uh delivering an aci uh working on project initialization tooling and then eventually mobile client libraries which uh we'll probably talk about in the future but the the one plug here is let us know

117. 52:10

     what we're missing let us know what you need let us know what's broken um let us know what you expect um and and we can obviously adjust this so i think with that it's it's questions if there's any other questions um i've got links to the github discussion here and obviously you can find us on discord and join office hours but i'm just going to pause is there anything else from the community

118. 52:34

     um yeah matthias asked um you said something about other ecosystems and curious what you meant about that by that yeah yeah so like one like from like a developer tools perspective um obviously we're trying to build everything that we think we need to build to make near like the most easy to use blockchain and to grow um we're we're hyper aware that there's other layer ones that exist that have solved problems um and and have really elegant solutions so we just want

119. 52:58

     to be able to give space for our team to investigate what those are um uh and again like this is i'm gonna turn this around to and ask um if there's an amazing tool from another ecosystem that you've used share it with us let us know let us know how like what what we've built so far is has maybe not met met expectations um does that answer that question i think it does um they they haven't

120. 53:21

     responded yes yes it does they they they said yes cool um awesome awesome you know yeah thanks for the update yeah uh again please continue to ask questions uh we got about five more minutes left uh cool some more coming in what about near cli rs is that actively deployed and thinking about how four point x would affect that um so yeah do we have any updates on near cli rs yeah so the cli and the russ sdk versions are not uh are not tied

121. 53:50

     together in any way like you can use any cli version with any uh any sdk version um it is being developed um it isn't like obviously the priorities right now are like these things that we mentioned right now um but is it is a plan to have like the the rest of the the rest right the rest cli be kind of have like first class support um and be brought up to feature parody with the you know the you

122. 54:13

     know traditional javascript uh cli um i don't know if anyone else wants to add any details i'm not sure what uh um one of their details whoever asked them curious about but um yes there is a plan to kind of uh push that along and make it actually like it is usable right now i i personally like to use it myself but uh as far as like i i don't know if it has complete feature parody um but hopefully with the with the next call there will be people that you know work on work on that and be able to give more

123. 54:43

     detail yeah i can give a little bit more detail too um so there so mostly it's like still mostly being developed on uh like as it hasn't actually been like prioritized as much just as what else has said but uh yeah like it will have like a lot more features uh in the future with like extension systems and like being able to uh add more stuff to it than just your normal near cli js version of it um like similarly to some of the

124. 55:22

     other cli tools you might as have seen like just being able to let's say i don't know npm add something and you'll be able to do it like npm a different sub command or something like that but yeah most most of this is still being in develop stage so not much progress has been made on that either cool um someone's asking about documentation for near apijs are more hands-on examples um yeah like i was saying before

125. 55:52

     nobody on this call is currently working on near apijs the wallet team uses it heavily and there's some individuals that are going to be contributing to um yeah updating that library specifically it is a very highly used library and it hasn't been getting the much as much attention as we would like um yeah definitely been hearing that from the community definitely going to be working on that in this next quarter they're already i

126. 56:17

     believe working on shipping new features in code around that but yeah i would love to have them a part of next month's conversation about where we're at with that library because yeah super important and uh really want to uh put a lot of love into engineer api js or or nash as we internally uh refer to it so yeah thanks for thanks for that question and then yeah i used to ask about examples another person said

127. 56:40

     something about uh these tools are nice are you also considering updating examples and documentation yeah that's on the devral team my team we are going to be we're actively hiring individuals and we're building up the team right now right now we've been uh primarily focusing on developer support in the channels plug for our office hours which we have twice daily if you go to near.org forward slash office dash hours you can see

128. 57:06

     when we have those in our in discord so yeah if you have any questions or concerns jump into one of those sessions with us live and and we can you know you can share your screen can walk you through code stuff like that but yeah examples are on the roadmap that we're currently i just kicked off a conversation with the education team and they're going to be partnering with us to help create a good um set of canonical examples for um

129. 57:31

     yeah for everyone because yeah right now we have the same examples we were just kind of patching them and making sure that they all work and not failing so you can see one of our new dev raw members dennis has been doing a lot of testing um in the individual repos making sure they're not failing and staying up to date with all the new versions that are being released but as far as more examples we definitely have that as high priority

130. 57:54

     and you can see more to come uh soon so stay tuned and uh yeah i love love the feedback keep it coming yeah one other thing about that is that the examples within the repos themselves are kept up to date with the code so if you are curious and want some examples of um all the latest stuff you can you can look inside either the sdk and the workspaces repos awesome thanks for thanks for flagging

131. 58:16

     that um cool um what is going to happen with mpx create near app um anybody anybody have uh uh comments on that yeah i'll i'll take it for now um uh like honest answer we don't know yet um so like when we work on like the project initialization um like problem like near create app is going to be a part of that um whether it's deprecated whether it's just updated is still very tbd um just to be completely honest um so i will we will share more as we figure it out and it's

132. 58:48

     not just gonna magically go away one day um we'll obviously have the community involved in in that decision making kind of an unsatisfying non-answer but it's the honest truth and we'll figure it out totally totally um cool well thank you so much yeah i said hey near seal irs is blowing near cl out of the water just saying uh yeah no there's got a lot of really cool features in there i'm really stoked uh to see kind of yeah like we built near

133. 59:13

     cli a couple years ago and having that time and space to kind of think about uh how would we want to do it if we started all the way over from scratch but yeah thank you so much for everyone for joining i'll look out for this video to be uploaded either later today or tomorrow and yeah see you next month if you if you want to be a part of any of these other um webinars we have one each week every

134. 59:36

     same time every thursday um check it out come in come into office hours hang out with us talk with us and uh yeah get in those github discussions give us some feedback we'd love to have you help us shape our future of our products and tools so awesome thanks everyone have a great rest of day bye