Welcome to October 19th, Microsoft DevSync. So we're at the start of a new sprint. And we're going to go through and do a quick wrap-up on the previous sprint. And then we'll see what's carried over and what new things we need to add. So, Chris, do you want to share your screen? And we'll take a look at the status of the current sprint. Sure. All right, these are just mine. All right, so it looks like those have been done for a while. So yeah, it looks like we got the database schema for UI elements done. Wow, we got a lot of stuff done. These look like there's just a lot to do with some rollover stuff. I guess I don't see a lot of Mark II prototype stuff. I don't know if that was expected or not. Maybe it's not aligned. OK, so let's go through the stuff that isn't done. I think we can skip the stuff that's in review unless there's anything in there that people are having trouble with. I guess, yeah, let's go through the review stuff real quick and make sure that none of that is actually being held up for any reason. OK, the change wake word file naming scheme, the only thing that's holding that up right now is that there's a configuration, a pilot configuration I need to make to get the CI to work. And actually, the pilot stuff is something I do want to maybe discuss during our summit as well. But anyway, once I get that configuration done, then the test score or the pilot's awful pass and it can be approved. That's the only one that up. OK, do you need somebody else's eyes on the pilot issue? No, I know exactly what it is. What I'm doing is I'm saving a kind of a global pilot file, pilot config file in our DevOps directory, our DevOps repository. And that file can be pulled in using the Jenkins files, can be pulled into each of our Python Jenkins files and then used to do linting. Can we put that in a public review? Good. But I don't know right now if there's no other repo that all of these, the nice thing about the DevOps repo is that all of our Jenkins files reach into there anyway for other things. Yeah, yeah, yeah. We could probably publish the contents of the file somewhere, but the reason it's going in there is just from a processing standpoint I needed there. I might. Anyway, I don't want to get into another thing. I may have started a new repo yesterday. And I might throw it in there. But I'll leave it at that and let your anxiety rise. But no, it's a legitimate good purpose repo. Don't worry. That sounds like something you should be talking about. Michael, while I'm looking at this, can you cut a new ticket for the SJ201 Rev-B enclosure-based scope, which could be the code that's where the board that Kevin is sending me tomorrow? Sure. Yeah. So the next one here is actually, I think the review is done, but did Ken, did you say we're just going to kind of scrap that anyway? Yeah. So what I'm going to do is I'm going to go through and clean it up according to the feedback I got and leave it as Rev-A, even though you don't like using part numbers as a naming convention. I will create the abstract case class though. And then Michael's going to create a new ticket for the Rev-B version of the board. And we can have both of them in our repository, even if we're just using Rev-B version. The difference is we're getting two boards. One is basically jumper configured to work the way the old one did, and the new one is jumper configured to do everything over USB. I have an update on that, but we can talk about it later. OK. Yeah. If I keep the Rev-A code, if we're not going to use it. What's that? What is it? Do I keep the Rev-A code? Yeah. I don't see the benefit of throwing stuff away. In fact, even the re-speaker stuff could be put in there under re-speaker. But yeah, I'm flexible. And all I'm getting at is that this is done only if you consider the fact that it's for the original Rev-A board, and potentially the one that emulates that tomorrow. So I'm just asking Michael to create a new ticket for the new board. Whether we care to keep them around or not, that's fine. We can throw away a code. I don't care. Well, we should talk about that in terms of, you know, maybe it would be better off in a branch. Do we want to handle these things through branches in the code or, you know, separate reposts? I'm not a discussant for right now. The way it's built, especially when it has an abstract days class, is that you just import a ledge, you import switches, you import the class for the volume. And then when you do that, the underlying code, based upon a configuration value, will bring in the board model version code. And it could have all of them there. And so Chris is just saying, I don't want all three versions, ReSpeaker, Rev-A, Rev-B, I just want the latest. And there's no need to fork it or branch it or anything. It doesn't matter whether you have three different sub-directories or just the latest sub-directory. It's fine. I don't care. Yeah. Okay. What's next on our review process here? Roadmap for initial release to community, guys? Yeah. I keep wanting to, like, flesh that out further, but I think we should just publish it as it is. And, you know, it'll get better over time. Has it been reviewed? Do we need to move it to somebody else who needs to review it? It's available there. Like, there's an overarching doc, that public document, draft public document there. So if anyone doesn't want that published, then let me know. Otherwise, it's going to get sent out. Yeah. I've reviewed it. You know, I think, I agree with Gez. We can continue to tweak it forever, but I don't see any harm in getting some feedback now. Okay. Can we move this to Don or are we going to leave it here, Gez, until you actually publish it? Yeah. Just leave it there. It'll remind me to paste it. Okay. Failing user deletes all alarms. Ken, who's that? That was a payout from me. And it might be merged already, I think. Yeah. Yeah. Okay. So this can be done. What's the next one? I might have, I might have already. Okay. There's a couple of times. Yeah. And the process status class. I have not looked at it. It's on my, it's on my list to review, but I have not, I've given some feedback to okay. And I think he's giving me some feedback back. And I haven't, just haven't circled all the way back around. So, um, and this other one here is real, is reliant on the process status stuff to be merged. So it's, we're document backup system for precise data. Joshua is, has that been reviewed by anybody? Well, I read it. Did anyone else read it? Yeah. I put it in the con form. It's a matter of whether you read it. It's a matter of whether you were able to restore from it. It's not, it's not designed to restore. It was just a documentation of the process by which we're backing up along with five new tickets for the things that we should improve in the future. So who should review this? Me since I'm doing the work behind it. It's a one page document, but yeah, go ahead and give it a shot. And you should be able to log into this backup server here and see everything coming through. It's by no means a comprehensive backup system, but I am, I do have a clone of your data. So here, and it is updating itself nightly. Did you see my email about what the different way cord directories before Joshua? I did not. My in, I did not. My inbox has 550 new emails in it today. Okay. I always find it to your initial message. So if you want to find it directly, there's some explanations in there.  That's what that's fine. I think that's good. And I think it's good that we have a ticket to review the documentation. I think it's bad. We don't have a ticket to validate that the data has actually been backed up successfully. All right. That sounds like something that you could do. I would strongly recommend giving it to Chris since he's changed the way everything's structured. And I have to spend some time coming up the speed on it. And I'm a little bit overloaded right now, but if you want, you can give it to me and just set it to a lower priority. That's fine. Is this related to the process status stuff too? No, that one's done. Oh, it's done. Yeah. Yeah. This is another pull request that was merged. Yeah. Okay. So we're down to a smaller, what about this, this patent thing? Is that still being worked on? That was just kicking it to someone for review. I don't know if Ken, you've had a chance to look at it, but or if anyone else wants to have a look at it. I didn't. I commented. Oh, I did not say the comments. Damn, you give the box. All right. Cool. I'll go have a look at that. All right. I'll sign this back to you then, guys. Okay. In progress. Derek, you have a couple of things here for Mark two documentation. Yeah. Well, so I'm still kind of going. Yeah. We kind of roughly identified it. But I want to shape it up. So I've got that in there. And then the longer stating. I mentioned this to Michael. So I just, I kind of want to get it to that. So. Derek, what I didn't see in there is whether you want to, how do you want to identify. That the mute Mike. Is active versus inactive. And are you intending upon. Doing any kind of visual validation. At the device and then a listening mode. Right. Yes. And we do like, so we have some of that already in the mark one. Listening. Because of animation. So. So for the mark two, the intention of being to do something to LEDs. The idea is that when Microsoft's not doing anything. But yeah, the doctor would cover all that. So, you know, say, hey, my problem. L. These light up. And the kids that it's listening. Et cetera.  So that's, you know, if it takes a while to respond to you. And that, that is something that I want us to do with the mark two as well. So after it's done listening, I transition to that. Et cetera. Okay. So we need to get this done quickly because the microcode that's going to be in the firmware. Be in the firmware for the LED controller. We don't currently have a way of reflashing that once it's, once that controller's, you know, been programmed. It can be reprogrammed. It's just that it can't be reprogrammed over the I2C bus. So, so every one of these devices right now, you know, is going to be using that firmware. The more devices we have out there that need to get that firmware reflashed, the more annoying it's going to be. So we need to have a good spec on how to use those LEDs, at least the first pass. That, so, you know, we're not setting up a bunch of devices that aren't going to be able to support this. Nice to see that Kevin's, when Kevin's demoing it, he's running something. Like, you know, he built something. He can do it, but like, you know, if you want to have lights that, you know, pulse slowly or have them all turned on at the same time or whatever, you know, you know, I imagine it's a fairly high bandwidth system that he's using right now. I want to keep it simple, you know, we don't, I would, I'd advocate for, we just do the brightness and the color of the LEDs on the bus and dump a, and just dump a packet, or I don't know how it processes information, but for lack of a better word, a packet and have it unpack the, however many lights there are out of the packet. And that way, you know, we can refresh it at 30 hertz or whatever speed we need, and we don't have to worry about the animations being, being built into the firmware. Yeah, we can do that.  I mean, you're talking, however many, it's not a lot of big. And then we just, we just, you know, update it periodically. Yeah. That'll allow us to go. Sure. Yeah. Guys, close the door and get out right now. Okay. Cool. Well, so close the door. It's on side. That's simple. It might blink a little bit, might use, you know, this kind of spinning thing. I think for thinking or for loading, that makes sense. So, yeah, but like Michael says, I need to get it. You know, I need to get it down on paper. So. All right. Michael, the Leonard first run of dev kits, does that plan completed? It is not. I need to have a, another discussion with, with Kevin about that. Basically, we need to finalize what our. PCBA vendors going to be, and we had some problems with the, the last one we chose. So. So I need to revise that. All right. Yes, how long before I get three of them? Yeah, good. I put some PowerPoint in there about what's remaining. And so we've, we've got a, chances got a draft. Like an example integration with Minecraft core. So that we can make sure that. There's no breaking changes. Before we actually cut the release. And so. And there's a little update to them, where the skill has to happen. Because of some of that weirdness that. Has previously been done. Like passing. Like equals none kind of thing. So. Yeah. Just got to, I think there's four unit tests failing and. In core at the moment. Which I haven't looked into yet, but I don't anticipate them being a big issue. And. And yeah, we'll cut a final point to release. And then the point three release. And that's in. All right. What about the benchmarking? Well, I've got you. Yeah, I've got a, I've got a few things. Particularly from a DJ. Is. Yeah. Yeah. I've got a, I've got a few things, particularly from a DJ is done. Much stuff. I want to do some extra. Things so that we can actually. Do it as much as possible. Side by side. Kind of comparison. And. But yeah, so it's still in progress. I'd say. Okay. But we should probably also think about, yeah, what's the actual. Ticket number. Precise 18. Yeah. But.  I'd say it's hard to get back with you on. File. Naming or. Directors stuff. Let me just see what I might have said that. But okay. Anyway, it seems like something that's not on the top of your mind. So let's just carry it forward and. Maybe. I'm sorry. Just JIRA. It just takes forever. No, I mean, I'm probably has to do with waiting for the tag samples. That's. Horrible. All right. Guest news and singing skills air Yeah, these these were Waiting on that process status stuff But we've also we've also done some fixes With some other errors that were happening around tests leading over into Future tests and so I'm gonna take another look in the context of that because Potentially there's something there and now that we've got that the micro plugs and stuff So I need to get back to this it just hasn't happened since I've done that fix so Okay, skill day time randomly failing That's in the same class like it's yeah, it was only failing on the on the CI process and stuff So the PCBA for our state to want it sounds like we already talked about that Michael So you're gonna talk to Kevin about that. Yeah, which ticket are you looking at? Oh? Yeah, there it is. Yeah Yes, exactly. That's still in process Okay camera mode evaluation Derek I haven't finished that yet still in progress Implementing tagger GUI a I was able to implement the changes that we talked about on Friday in our meeting with the exception of How to get from one question to the next where it's obvious that we've switched questions So I'm looking at an angular as an animations Library I'm looking at doing something like sliding one in sliding another one out or something like that So that is the only thing left to do for this GUI that implementation that I can think of Okay, great So what's our process for getting that out in front of the rest of us to test and then getting it out to The community to test and then rolling it out.  I mean, I think I know Some sort of test folder in the in the On the NAS that can I can get to test files with So it's a little work to do to get all that set up so that we can test with it, but that's I'm planning on doing this week That so we don't accidentally pollute The data source if something's not working correctly. Is that the thing? Yeah, yeah, well, yeah, it's good to have this was especially we're gonna be doing tag and tag You know, if you're just testing something you could incorrectly tag it, you know, just to test something so I don't Point it's a production data test the tagger Well, when we deploy it for internal testing we should be using it Well, we may want to test some malicious use as well, right? So we'll have to Yeah, and if anybody has the has the bandwidth to do it point your Point your device at the test API as well So you can you can submit your own samples as part of part of this change is the you know the collection of submitted samples as well so That would be useful to test I have been pointing mine at a completely non-existent URL to test out the you know Hey, my car that works and what is your line? Just before I address The personal pronoun use my personal pronoun both singular and plural I should finish this today. Hopefully and move on to getting everybody Set up so they can test it themselves Hey, my craft What is your writing update service from work to you Joshua? My next work IP address is still working on that hand to core has built our update service for us and I've been from pretty significant I'm working side of Belina in the last week and still haven't heard back from from a boon to about some of the questions that I asked So it's still open. All prototypes should have an enclosure and core version in the chemical place settings Let me talk about this. Let's Just add us on this Ken so this is the Ticket where we're going to try to capture More about the surrounding environment than we do right now when we pair a device. Is that correct? Yeah, we pair device. What are the enclosure and core version? Yeah, and there's nowhere to report that information to right now So until such time as we have an API that will accept that additional input I haven't moved forward on it That probably was in progress I would put it out of in progress because I don't see that API being available to sprint Well, what the API that would take that information is the for example the wake word submission API, right? No, no, no, no This is the enclosure. This is the reporting of what environment we are running in What version of core what's the operating environment is the mark one and mark two is at your laptop? Whatever problem is we don't have an API to handle that extended enhanced information right now That would have to be done during pairing I assume since it doesn't change but until that API exists There's no need to do the actual work to post to a non-existent API So my recommendation is to take it from in progress and put it to do Okay, let's take let's put it into do and set up a short meeting to discuss that because I think that it's something that we can implement But we we need to design it first Yeah, we just need a back-end API that will take that information If we if we're only talking about the platform like a platform designated like mark two and then a version number for the platform And then core version number all of those things already exist in Selene correct Okay, but if you look at the ticket, there's more information than that if I'm not mistaken Right, right, right. Okay. I'll set up a meeting to talk about that this week when it's where that skill is a bit of a nightmare It's like it's a terrible thing. It's just lots of people working on it over the years So I Have started refactoring it a bit. I don't want to I know we don't want to like do a huge fix of skills but Anyway, the problem comes down to like the way that we're we're pulling in data and Trying to get a forecast for a previous day Anyway, I'm working on it still The assumption is forecast previous days are always 100% accurate Yeah, it's just that the API is like we don't have a forecast for yesterday because that's not a forecast, you know Okay Can the next two are yours The view architecture of core with respect to boot up and drivers Can you open the ticket? I'm sorry. I just don't have my large screen. I was supposed to be back at the house and I can't read it Yeah, this is still in progress, this is this is a piece VK test for wakeward tagging so Yeah, so I've been vk testing but Not for tagging because to the best of my knowledge Tagging is not ready to be tested yet Not nor is upload did I hear earlier that the upload wake word is API is working in test or no? It's the code is merged into dev. I don't know if it's in test or not off the check So Yeah, what I've been doing is and I'll just give you my status. I guess while I'm here This is what I've been working on but I refactored the stuff we had for precise I broke it out in the three things precise performance precise operation precise upload Everything's working except for precise upload which once I turn the URLs on they should work So that's what I had done but leave this ticket open because I'm also going to be adding the wakeward tagging stuff into those tests as well I'm assuming and I don't know that this is a valid assumption that the tagging tests Will run in a different location then our current VK integration tests which in core is that correct? Yep And is there a reason for that? Because the codes on Selene Okay, but Selene is a back-end service that can be tested from core, right? Not that tagging stuff is nothing to do with court That's true. Okay. So yeah, then that'll be located in different place once it's ready to go But I haven't started those yet. So leave this open. Okay, and Josh, you're still working on the third-party Management, so what's the difference between the canonical Mark 2 171 and mark in my C4 155 One should be a subset of the others Okay, the canonical is a subset of the brother ticket. It was created before it though Yeah, what are the you know the one you were just asking about the? Mark 2 171 ticket is that's the overarching one, right? We need to find a you know find a system that's we're gonna use for updates And then I believe he's got separate tickets for each different system that he's evaluating Okay Okay, so this is super exciting I Can already tell that we have either bitten off more than we can chew or kind of gotten distracted along the way here I Think that we should just roll this sprint into the next one. Let's close this one out and move all these tickets over into number 17 and Rather than trying to add new things And try to fill out the the two weeks. I think let's just take this week and try to close out all of these tickets And anything that's not Closable this week We should You know rethink Maybe it's maybe it needs to be split up into you know separate tickets or maybe it's just Things that need to be kicked back into the to do But you know if we're not making you know enough progress on these things there's got to be a reason it's either you know lack of lack of time or Something blocking them Yeah, I'm wondering if like especially with the the tagger for example, you know That there's hundreds of lines of code I've written for that that probably could be splitting up That's a smaller tickets to really show my progress you know, and I wonder if that's the case for Some of these other things that we were making the tickets big enough that You know They're spanning multiple sprints Just a Observation, yeah, I mean, I guess I'm less worried about Demonstrating progress. I'm assuming everyone's doing good work, but I am more concerned about Things getting lost in the shuffle because there's too many things open and people are working on too many different things at one time so let's just close some things out and include some path ahead of us for getting more stuff done I Had a chance to figure out what we were talking about earlier when I couldn't see the ticket That was the automate thing and that's simply that that's ready to go except I'm waiting for the API to be able to grab the files to Determine whether we want to continue training or not. So that ticket's remaining open until that code is done Yeah, and then I can actually close that out by validating that it made it through a run Okay, that sounds like another thing you should connect with Chris there on Just to go through Check your assumptions regarding that API and see if what he has implemented will satisfy those or you need to be something else Yeah, Chris is that API ready or not yet? I mean, I it'll be have a PR here in a little while So if you want you can bet review the PR first and then And then yeah, like I said this week I plan on getting everything into our test environment soon all right if you can just Matter most me the PR request link I can take a look at it and see what the API is providing and That was Cool So I'm I'll provide just a little update on the mark to Before you go Michael add the ticket for the new mark to enclosure to the sprint. Yeah, I've got a list of tickets I'm gonna add a minute Okay Okay, I completed 616 or now on 17. I'm gonna go ahead and start it so we can start a lot more up to it So Okay, so a quick update on the mark to the sd201s that we sent out for the US based manufacturer and paid a pretty penny to get done in very fast turnaround Have not been delivered yet not even shipped. They're running into some problems with their double-sided assembly and Kevin's currently debugging that fortunately Kevin also very cleverly ordered a backup set of boards from a Chinese manufacturer and they came in first and so over the weekend He was able to get get it up and running so we've got some he sent us some demo videos of that and so the system is fully working and He's sending those to Ken Right, you know today, so it can't you get them, you know within a day or two And we can start getting that enclosure code working so So Ken You've got you got a couple days to clear your schedule for Getting to work on that Before the meeting and they'll be here tomorrow morning and he's sending me one of each Jump one jumper to behave the old way and one jumper to behave the new way So So we're supposed to be able to use the boards we're getting from the more expensive us being your back to just get them later, right? Yes Unfortunately, right? Yeah, yeah, we go and after them for the for the additional rush fees and everything else I get all that stuff back if I mean the value is you can deliver it quickly if you can't deliver it quickly We'd expect an appropriate price I we have to I have to figure out what the exact problems are it may have been related to the Of the double-sided assembly and not just to you know the turnaround Because all the boards that we've gotten working so far. We've only had the PCBA You know factory assemble one side and then Kevin's hand soldered the second side So they may be running into some design problems with our boards You know that they just don't show up when you're only assembling one side on the automated automated line So if we can if it comes down to that then You know, then it's probably not their fault but But yes, I will definitely have a very keen interest in making sure that We're not paying for something we didn't get so that being said we should have ten of those boards Out by the well in the next couple of days Kevin's actually got another project. He's got to work on So by Wednesday, I think he's gonna send out eight or ten more boards to the rest of the team Well, probably to Derek to get turned into things. Although maybe we'll send half to Josh to Depending on what what how your 3d printers have been working But we'll figure out how to send me a bareboard Okay, yeah Yeah, so I my my 3d printers are working my 3d printers are working. Okay, though. I Haven't started. I'm printing enclosures as fast as the little printer can print and I put a new print head on that guy After six years, the other one was Derek. It was this nasty black mess of gross and it's printing. It's printing great Here's a here's a new enclosure from you or for the For the mark to I'm writing a memo right now on Strategy so if we definitely need to talk about that, but I'm super excited to have everybody out and Actually like like walking out of this this get together with a working mark to like hey It works because there's a couple of blockers on the sales side of things that that we need to resolve and in order to Resolve them we need a working mark to just one, but we need one that works okay, so Let's uh, let's just like I said, let's spend the rest of this week working on the tickets that you that we've inherited from last sprint and We will Let's we'll check in on Friday and See see where we are and After this print That'll also give us some time to know where the mark to is as well This meeting wasn't nearly long enough, so let me bring a couple of points up the first is somebody mentioned something about firmware and burning the Current model or the next version of the board we have coming out as a separate Microprocessor on it and the only way to change the code on that after it leaves our factory Is Additional hardware You know it is not programmable in the field And there is no easy way to make it field programmable at the current time without additional hardware and Speaking to your point Josh If you want to leave after their summit with working mark to We should probably figure out if we're going to use the kivi or qt image And get somebody working on a soft keyboard if that's the solution Wi-Fi setup Indicative of the fact that it is not going to be a trivial one-day issue Yeah, so the Wi-Fi setup we do have a solution for that So if we can get into that and the kivi versus qt thing I sent a back channel message in the middle of this meeting to Michael and that is entirely on Michael's death So I will I will defer if you were to have me make a decision today I'd be happy to give it to you, but it's not my call No, the all I'm getting at is that that decision is going to drive How your soft keyboard is going to be implemented and at some point in time somebody should probably evaluate Whether in our environment the soft keyboard will work at all I started down that path I don't really I don't honestly don't care if it's not keyboard works I'm firmly in the Chris Bayer camp of we should not require a keyboard for our thing to work We are a voice company and I do agree with requiring a second device But Molina publishes a Wi-Fi setup that we can use right out of the box You know, we're probably gonna have to spend right around a day Hacking on it to get it to work where we would you know provided our chips efforts, but it's designed for Raspberry Pi 4, so I don't anticipate that being an issue on the kivi qt stuff you already have an answer on that but that's the Getting a working mark to working on the sprint is not a like hey, that would be nice sort of thing It's like a hey if we're gonna have jobs next year. We need to make this thing work like we've been goofing off with with this I Maybe that's probably not the right word But we've been working on getting something out for a really long time and the places where we need to be focusing our efforts According to the financial model that Johnny and I ran this morning is on adding value added services to get people on to our If we cannot get to the point where people where we're adding value and people subscribe then we're done We're done so we need to get the mark to out because that's the blocker for Description that's the blocker for getting out in the retail That's the blocker for starting to focus on mobile devices There's all these other things that are blocked by this 40 really need to get on block and I have every confidence But if we put everybody here in this shop, I'm probably need some more tables But we put everybody here in this shop and just rent like I think we can get amazing things done I have a lot of confidence in everybody. Yeah, I just want to make sure I understood you correctly So you're saying the Wi-Fi set up to trivial issue. Don't worry about it. You're on top I Trivial issue I have confidence that once we we approach the problem as we're implementing an existing library That you can get it done Well, I would feel a lot more comfortable if you forward me some documentation. Well, I could potentially sign up for that Well, so if we get this if we get the audio stuff working on the SJ201 There's a lot of stuff we can look at, you know, we can look at the Qt image that guys has been working with The guys well, you know, I've been kind of in there too, but working with the guys Blue systems to see what can be paired down to make it run faster The soft keyboard works on that we can evaluate all kind of We're putting in a Wi-Fi password somebody has a solution that's just already to go out of the box I just sent it to you and what's that I just sent it to you and what's that have a look Davis Jarvis is often helped to pull the mark one enclosure stuff out too. So I think we should definitely take him up on on that offer Yeah Just means we need to we need to have a good idea ourselves about what that enclosure looks like. So which is already a ticket in there. So What do you mean by pull it out? Well, I just you know, how there's all a mark one code like sprinkled through my crop core Trying to pull that out into an actual enclosure Code, you know, it's only enclosure code Yeah Does Jarvis just does Jarvis want to Come visit Hawaii for a couple weeks Why don't you why don't you put that on the table? We we can't pay We can't pay salaries and stuff But if he wants to come sprint with us for 12 days and agrees to kind of focus on the focus areas where we're focused on He can be our virtual gas interface. So You can be here and and do some work. But yeah, I'd be I Certainly would be open and I think that the The amount of input that we could get from having another developer who's thoroughly Thoroughly familiar with core far outweighs the cost of tickets to Hawaii and lodging for 12 days. So You want to you want to clear that with Michael Michael you not to put you on the spot You know what Michael and I had a little conversation about about oh, he just said yeah, okay So yeah offered up. I don't know where he is. Where is he? Portugal But yeah, I Yeah makes the offer and then you know, I let him know it wasn't good faith that I didn't realize he was in Portugal if he was anywhere Yeah, it might not be doable Yeah, and be sure to just put a put a tweet out there to the real Donald Trump to thank him for the fact that he can't go to Hawaii Yeah We did also talk about implementing doing using the plug-in system for enclosures and whether that could be a useful idea and So just starting a bigger discussion about what enclosures look like Well, there is a an interesting idea about creating a new branch of a new Experimental branch of my cross core that is you know free for our community team to Just merge Whatever, you know features they want into it so that they can like go to town on on playing around with things Yeah, it would be a centralized fork Yeah Hey The whole idea would be it would be like everything in here can break at any moment. It might be reverted at any moment Is it like it would either be it lives in our repo or it lives in like Jinx is jinx or Jarvis's repo or something like that, but I guess the benefit of doing it out Yeah, I mean if it's gonna live in anybody's repo, I'm very open the host to get internally if it's gonna get done anyway I'd rather I'd rather keep it in house my thinking is that it reduces the chance of a a noncom of an actual fork of the project and then you know them trying to Run their own thing and oh, anyway, I Don't want to get into that discussion right now though. I just thought I'd you know sure something to keep the meeting going Jarvis playing a hostile takeover without your telling me No, they intentionally don't want to They like they want the ability to you know add in all these things that they're playing with that They understand that we need to test things properly and that we have limited capacity to test all that sort of stuff and They don't actually want the project to fork and become you know separate and then become the kind of thing where you can't actually Become you know diverges so far that things no longer work from one to the other and they know that that is bad for the project so Yeah, I think it's a you know Because master is fully state is our production branch dev is going to be production We don't want to merge things in there if they're gonna break and so this would be like, you know You could like they could they could merge things in there without without one of us reviewing them and It breaks and everyone that's using that Trace the hands up in the air Yeah anyway This code you this this link you sent me from Belina as soon as we have a working access point Chris Is there a working access point currently in the? Mark to image Keep in keep in mind Ken that the Belina code is written for Raspberry Pi 4 So it's that there's some questions in there of like hey does your platform support like if it's a feature in there It works on pie, so you don't need to ask the question it works on pie But if we were working like some other rando board, yes, you that would be a good question to ask It is what micro OS users which is now filled the open voice operating system Chinks is Yeah, micro based OS. That's what they use so it can work Sounds like everybody's more confident. You want to make sure that's that's our friend who was using the brand with with Where we hadn't published the brand standards yet, and so he he was he was experimenting with our stuff I do want to I do want to make sure and I don't know if we made the offer You know we can officially endorse like help with that side of things. We just can't have them use the brand Yeah, we have our brand our brand use guidelines. Okay, like it. We're not sure. I want to make sure that Very happy with it. He fully understood Okay, and we'll write a blog post about how awesome he is in the whole bit like I'm more than happy to do that Yeah, yeah, I thought we'd add it to our community releases section on the get my craft even essentially Anyway He's doing really cool stuff in that in that project though So it is Qt base, but it doesn't it doesn't have even have a plasma session running and I think he's running directly to the frame buffer somehow, but Anyway, this is unintentional delaying the end of the meeting now. So I Mean I'm concerned more concerned than everybody else I sure would like to have a meeting on how we expect this Wi-Fi stuff to work it doesn't have to be this meeting but I think it would be helpful to have that meeting before we get out to Hawaii I I show you a concern I just didn't didn't think right now is the time Go chiefs Go chiefs


Hi everyone, thanks for coming. Today I want to spill the beans on things I've learned writing a number of popular Ember add-ons and share thoughts on the four things that I think make an add-on good. So firstly, my name is Lauren. You might know me as Sugar Pirate. And my skills include dad jokes, ordering bubble tea for my colleagues and then drinking all of it, and being Australian. Because of these highly valuable skills, I work at Netflix on applications that power the world's largest studio. So come to our booth later if you're interested in what we're up to. So add-ons, chances are you've used one. Raise your hand if you have at least one add-on in mind when I say good add-on. Oh, that's awesome, it's a lot of hands. So last I checked, there are actually more than 3,500 add-ons in existence if you check the emberaddons.com website. And in the beginning when add-ons were first introduced, it was actually really tough to write one because a lot of features didn't exist in both Ember and Ember CLI. And in the past you had to resort to like hacks or intimate API to do certain things. But I think we can all agree that add-ons have gotten pretty great over this time. But out of 3,500 add-ons, how many are good? This was the question that made me think about this whole talk. And I have a very simple theory that there are four major things that go into contributing to what makes an add-on good. So firstly, the add-on needs to solve an interesting problem. It doesn't have to be an extremely difficult or challenging problem. Something simple done well could still qualify as solving a useful problem. But it has to solve it so well that someone else would rather use your add-on than to build it themselves. Secondly, it needs to be straightforward to set up and use, and that usually means good documentation, examples, and a low barrier to getting started. And honestly, I think this is where most add-ons fall short. Third, the API needs to be delivered. It doesn't have to be perfect, but you do need to put some thought into it, and it can't be an ad hoc API. And this is really tricky to get right on the first try, but thankfully that's why semantic reasoning exists. And finally, it has to be reliable. Or in other words, it also needs a meaningful test suite. And this is especially true for add-ons that aren't presentational. People want to use your add-on to solve problems and not cause more problems for their application. And a test suite is a good way to give people confidence about your add-on. So which add-ons for this bill? There are many, but these are some of the more popular ones. We just listened to Mac T's talk about Ember concurrency. I have talked about it a lot. My coworkers are probably bored to death with me talking about Ember concurrency, but it's probably my favorite add-on so far. It's got really great documentation. The API is very simple as you just saw, and it solves a really difficult problem. Ember power select is also an add-on that hits all those four points, in my opinion. And you would think that a simple select dropdown would be simple to build. It's just a simple select, or how can it be? But it turns out it's not that simple, but Ember power select makes it a really nice experience. Liquid fire, of course, needs no introduction. Provides a very nice declarative DSL for you to declare animations that were previously not possible. It's also very easy to use and very well documented. And finally, Ember CLI deploy deployment is so different across different teams and companies, but Ember CLI deploy is flexible enough to handle all, or if not, I mean most if not all of it, and it's also very sensible. And these are just some of the more popular add-ons. Now when it comes to running good add-ons, I think there are many approaches, but personally I like to practice DDD documentation-driven development when I make a new add-on. Documentation, document, okay I'm not gonna do the whole thing. And the main reason is that it helps me think ahead of time what the developer experience should be. You know, what kind of API does this add-on need to surface, and then from there, you start to write tests and you can do a test-driven development against that API. Because it's true, if you don't document something, how will they know that it exists, or how will they know to actually use this feature without spending hours digging through your source code? Some languages even rightfully treat documentation as a first-class citizen. So this is Elixir, and the examples in the comments in gray, they can actually be run as tests. And unfortunately this isn't a language feature in JavaScript, which is really sad. But documentation is so important that some add-ons even have their own dedicated documentation sites. While this is really nice to provide, by no means is it required, you can certainly have very decent documentation with a markdown-based readmealone. And this is typically the place you should start anyway with documentation, and you can always visit making a fancy pants doc site in the future. If you are in the habit of commenting your code with JS doc or UE doc style comments, then you can also find add-ons or other JavaScript libraries that will help you generate documentation. And even if you don't, they are still a really good way of teaching contributors how to contribute to your code. So let's say you've done all of that. You have an add-on that solves a really interesting problem. It's well-documented, has a good API, and it's well-tested. Now what? Well, in most cases that's not sufficient by itself. And the thing is, and this applies not only to open source, but generally speaking, projects require two things to be successful. First, it has to solve a problem. And if you've done those four things I mentioned earlier, you've already got this in the bank. But more importantly, building it isn't enough by itself.  And again, this is not only true for open source, but many things in life. There was this really great talk at ReactConf by Chung Lo on the meta language and what he describes as the meta language is the stuff that goes beyond the code. So these are things that like blog posts, videos, conference talks, documentation, whatever else, a thought leadership would be a good one. These things are really important, but they're not codified into the library or the language. Of course, anyone can build an add-on, but the project doesn't end when you hit NPM publish. In fact, it's only just started. Luckily for us, there are many ways to spread the word. You can write about it, you can record a talk, record a video, you can do a talk at a conference, like MacD, and people do wanna listen to learn about it because no matter how mundane or technical or boring you might think it is, it's also a really important step in getting feedback so you can improve on this library. But if you're like me, despite being up here on stage, when I create new add-ons, I tend to write about them first. Personally, for me, writing has the best ratio of effort to reward. Writing helps me communicate my ideas better, but I think your mileage might vary. And as an aside, I'm still running this Emberway publication, so if you do wanna write about something that you've written, let me know and I can help you publish it. So in this talk, I wanna share my experiences and lessons learned writing add-ons, and hopefully it can also inspire you to start writing add-ons of your own. So first, let's take a quick look into what exactly goes into an add-on and how to think about an add-on structure. So when you generate an add-on for the first time, you'll notice that the folder structure looks very similar to an Ember application. But one of the main differences is that it has an add-on folder, but otherwise it mostly looks the same. And there are a few things to note though. So on a high level, the add-on application and test folder live in Emberland and in these folders, you're actually working in the framework itself and Ember CLI helps glue it all together. On the other hand, there are folders which are in Node Land or in other words not in the browser and these are all files that are used by Ember CLI when the add-on is installed into the consuming application. Now in the add-on folder itself, we can think of it like a source folder for your add-on and most logic lives in here and these files won't get merged into the consuming applications tree unless you also export these files in the app folder. As a rule of thumb, I only export things that are part of the framework like components, helper, services and so on or other parts of the add-on that people might want to override. So here in this example, we need to export this helper so that the user can actually use it in their template. But if the user has an append helper already in their application, then that will actually take precedence over the add-ons helper. So in that way, they can override an implementation if they need to. And this is really important to think about because you want to be deliberate about what gets merged into the consuming application and you don't have to export every single thing in the add-on folder and it's often not recommended and you can think of it like exporting is making something publicly available so and you don't really want to make everything publicly available. Now in scenario where another add-on conflicts with yours, it is possible to specify which add-on will win. So here, Ember Chain Set Validations which is a plugin for another add-on called Ember Chain Set. These two add-ons both define a chainset helper but I wanted the Ember Chain Set Validations helper to win. So here you can actually be very explicit and say that this add-on should be installed after Ember Chain Set and therefore its helper will take precedence. One thing to note though is that even if you don't export something in the app folder, it doesn't make it private and consuming applications can still access it if they know the path to it. And it is very easy to see all the modules that EmberCi knows about. I'm not gonna tell you what the command you need to put in the console to see this. I'll tell you later if you want to know. But keep that in mind so there's no real concept of private modules here. In addition to the add-on and app folder, add-ons can also introduce blueprints and blueprints are interesting. You've definitely used one before. These mostly look like JavaScript but you'll notice the ERB-like syntax, the embedded Ruby-like syntax where you can put these, I don't even know what you call these, arrow percent equals. And these will be used by EmberCi to dynamically inject different things into these files when they're generated from this blueprint. You can also look these up on the EmberCi docs. These template variables are provided to you by default but you can also define your own in your add-on which is very useful if your add-on is extensible in some way. One thing I also note about node LAN is that you get access to the add-on hooks in the index of your add-on. And these let you work with the add-ons build directly and you can do a lot of things here like include custom EmberCi like commands, you can include, choose files include to exclude, you can add preprocessors and so on. So let's go through some examples of add-ons that make use of these hooks and see how they use them to do the features that they include. Ember test vectors is a really great add-on by the folks at Simple Labs, the same people behind Ember Simple Off. And what this add-on does is that you define a data test selector attribute on your HTML elements. And then this test selector can be used in your tests to select elements. But the cool thing about this add-on is that it will actually strip these data test selectors away in environments that you tell it to. So you don't have to pollute your production HTML with unnecessary attributes. And to do this Ember test selectors uses two main EmberCi hooks. So first it has a preprocessor to walk the tree and then it finds and removes those data test selectors from your template. These test selectors are very useful again, instead of selecting something by its class or its ID or whatever other attribute which can be very brittle. If you, for example, you change the class name because of the styling, then it's really good because the test selector is decoupled from the presentation. Ember test selectors also makes use of the tree for add-on hook in order to remove itself from the build if the test selectors are being stripped out. After all, the add-on becomes unnecessary in production, right? Because if you're stripping out HTML, why do you need test selectors? So it will actually remove itself from your application and it will bloat the final production asset. And then Ember Composable Helpers is an add-on I co-authored with Martin while I was at Dockyard. It's a relatively large library that includes a lot of helpers. And it doesn't really make sense to include all of them if you're only using one or two in your application. So we use the same hook as well to include or exclude specific helpers from your application. In the add-on, the tree for add-on hook will call a filter helpers method which then uses this regular expression to test what file names it needs to include or exclude. And then based on configuration in the consuming application, we can be and say like, oh, right, I only need helper x, y, z and I can just remove everything else because we're not using them. And finally, Ember CI Deploy is an add-on that we use a lot at Netflix. It makes use of custom commands to give you a really nice interface in which you can deploy your applications from the command line. And the nice thing about this is it actually helps you make your deploys automatable so you can have, for example, a CI build deploy an application after a test suite runs or whatever else. And custom commands are really simple to add to an add-on. Ember CI Deploy defines them in a separate folder which also is a nice way of just separating it out and not having this massive index.js file in your add-on. So I've written a couple of add-ons now and throughout the experience, I've learned a thing or two, a few hacks here and there that I wanna share but don't use the hacks. So first, I wanna talk about the developer experience. It's really important to think about how others will use your add-on as you build it. First, in your documentation, it's super useful to describe why the add-on exists and what it does. That's something that's actually missing from a lot of add-ons, like, what does this add-on even do? Why does this exist? Tell people it's really important. And you don't need to write an essay worthy of thought leadership. It's just describe it simply. Just a little bit of explanation goes a long way in helping people understand the goals of your add-on, how it helps them solve a problem and how they can even contribute and make your add-on better. Next, it might be obvious, but you should explain in detail how someone might use your add-on. Again, this doesn't need to be a fancy website. And then depending on the kind of add-on you're writing, this might make sense for library kind of utility add-ons. I will typically detail how to use the public API for an add-on in ways that I anticipate they're used. So, you know, it just gives like a simple example of how you use this feature to do some, like the 80% use case. And I take inspiration from documentation, like from libraries like Lodash and Ramda, for example, but this doesn't really work for all add-ons. You know, it really depends on the kind of add-on you're building. You know, if your add-on introduces a new way of thinking like Ember Concursy, for example, then this kind of documentation isn't enough and you definitely need to explain your ideas more. And if you do have the time for it, it can be very effective to create live examples of how to use your add-on. This shows off your add-on directly and gives people more confidence that they'll be able to use your add-on to solve your problem. So here's a really nice real example on the Ember Concursy website.  And it's even more appropriate when your add-on is presentational. So, for example, Ember Burger Menu, the demo site and documentation site, literally dog food is the add-on right there. It's awesome. And Ember PowerSelect, again, also does a really great job here. You can actually try it out in the docks itself. But if your add-on is presentational or if you're lazy like me and you don't want to put together a whole fancy site, you can use Ember Twiddle, which is really great. I think I'm not sure when, but Ember Twiddle now has add-on support. So we can actually install an add-on into a Twiddle, which is awesome. Thanks to all the Ember Twiddle people. And personally, I like this a lot because it becomes a live playground that you can share and people can actually try out your add-on and edit it a little bit and see if it works for their use case. And this is actually kind of like, try before you buy, right? Another thing that seems obvious is that your add-on needs meaningful tests. The good news is that Ember makes your life relatively UV now, thanks to all the awesome Ember CLI folks. For example, by default, your add-on will run tests against different versions of Ember. This is all by default, you don't have to do anything. But in some cases, if your add-on explicitly needs to support like a really old version of Ember or a very specific version of Ember with some weird edge case, then you can actually test that explicitly in the Ember Try config. And yeah, this is really useful. And if you also use Travis CI, which is free for open source libraries, then you can make use of the build matrix, which will let you specify different variants of the build to test in parallel, which is really nice. And you can even also specify which of these builds are allowed to fail. So, you know, if you see at the bottom, I'm not sure if you can see it, but Ember Canary scenario is allowed to fail. And this should give you and your users more confidence that your add-on works as expected in different versions of Ember. Additionally, it's also possible to test your add-on and your application against a real browser. There are various ways to do this. For example, in the future, you might actually use Headless Chrome instead of Normal Chrome. And there are a lot of add-ons that actually do this. So you can check out their Travis configs, for example. Now, one more thing that's crucial for a lot of add-ons is the ability to configure them in some way. And this is one area where I feel it's not super straightforward and there are a lot of ways to do so. But I don't think it's documented very well. So the first method is one that I saw was adopted by LiquidFire. So in LiquidFire, there is this file called a transition map, which looks very similar to a route map. And you place this file in the app folder of your app. And somehow, magically, it knows how to pick this transition file up without you doing any other work. And this is really nice because it makes configuration quite painless. So let's look at this transition map a little closer. So what is it? It just looks like a really simple export of a function, right? And somehow this functions context, you know, the this keyword, you know, it knows how to define transitions, it knows how to define all these other really nice DSLs, very similar to Ember's router. LiquidFire makes use of the Ember resolver to locate this file and then invoke the function with the new context applied to it. And this is slightly intimate API here because I kept it small. But you can see that these three basic files app.js resolver and router.js, you actually can locate them with the factory with their magic incantations. And factory four is a new feature. I think it's already in Ember. But if you're all supporting an older version of Ember, you can use the Ember factory four polypool so you don't have to use that intimate API that I just showed you. Now, there's nothing special about the transition map. For example, it exports just like any other JavaScript file in Ember. And that means in your scenario, if you're making an add-on, you could say, you could tell your users to export a plain object. You can export whatever they want, whatever you want. And then your add-on can look for that file and then pick it up and do the configuration there. So it doesn't have to be a function like in LiquidFire. That's just the way LiquidFire decided to do it so that they could have a nice DSL. Next, you can also have your user define their configuration in the config environment file. This is generally an older practice, but I think it still remains useful where you want your users to be able to configure your add-on differently in various environments. So for example, Ember Metrics is an add-on I wrote that gives you a nice API on top of various analytic services like Google Analytics, Mixpanel, so forth. So you can actually track events or page views with one API instead of having to call like five different services in your application. And in this case, it's actually really useful for us to be able to do things differently based on the environment that the application is being built in.  And so configuration environment that file seems like a really great choice for this add-on. And Ember Metrics installs an initializer into the application that imports this config file, sorry, the configuration, and then registers it in the container as config colon metrics, and then that object is injected into the metric service so that the service can access the configuration.  Note that this is all defined in Ember Metrics itself, so the consuming app doesn't need to do anything else. So this is really convenient. And another popular option is to make use of the Ember CLI build file, and this is a good way to allow configuration that happens at build time. So again, Ember Composable Helpers comes with a lot of helpers as its name suggests, but you don't want to bring in everything, so we let you configure it here where you can say like, I only want the increment helper, I only want decrement, but accept pipe. Yeah, you're not supposed to use them both at the same time, is this an example? And yeah, this is all handled in the add-ons index file, so the included hook lets you modify what goes in the build, you can whitelist and blacklist, and then if you have those functions returning new broccoli trees, then you can exclude or include those offers. And then depending on the kind of add-on, it might also make sense to allow users to extend it based on their needs. So again, with the Ember Metrics examples, it ships with some bundled adapters for different services like Mixpan on Google Analytics, but it doesn't define like an adapter for every single thing. And the idea is that with extensibility, we allow users to define their own adapters so you can write an adapter for your application against your bespoke analytic service or something else that we didn't build. And then this is also nice because it also strips away the adapters that you don't use. And these adapters are just plain Ember objects under the hood, except that the service, the metric service expects them to implement some specific interface. One thing to note about this approach though is that these plain Ember objects are not managed by Ember's container. And what that means is that you have to manage their lifecycle yourself. So you gotta delete them or destroy them, you gotta initialize them, blah, blah, blah. And then here in Ember Metrics example, we have a base adapter that all adapters inherit from. It doesn't really do anything but throw errors if you don't define a required method. And then each adapter will just implement those methods and you can start using it in your application. But the interesting part is in the service itself where we need, so even though you created an adapter, the metric service doesn't know that your adapter exists in your application. So we need a way for the service to discover them and essentially what Ember Metrics does is it uses the names that you specify in the configuration and then it tries to look it up. First in your application and then in the add-on. So again, so you can override the Google Analytics Adapter for example if you don't like the base implementation. And once you have a reference to that adapter factory, then the service can now just instantiate these objects as well and delete them and so forth. And yeah, that's a pretty nice way to do it. Okay, and then there's the approach where you operate outside of Ember. This is the dangerous part. So note that I don't recommend this approach but I just wanna talk about it. So in Ember Chainset Validations, which is a validation library, validators and validation maps are plain functions and objects, they're not Ember objects. So what that means is that we don't get access to the container.  I kept this font size small so I don't read it. Again, I don't recommend this approach but in certain cases, hacks are useful, right? Yeah, don't do this. And yeah, again, in certain cases, hacks are useful. A lot of Ember, a lot of Ember and Ember through I start out as hacks but in a way hacks allow library authors to determine what the optimal API should be and I can see Rob laughing. But yeah, sometimes hacks are okay but at your own risk. Another way to provide extensibility is the approach that Ember Service Worker does. So Ember Service Worker, the base add-on doesn't really do anything except take care of some basic infrastructure. And then in order to actually get some service worker functionality into your application, you need to install plugins and these plugins all do different things. So how Ember Service Worker does this, it looks at the Ember Service Worker plugin keyword in the add-on. So it actually can look at the add-ons, these plugin add-ons package JSON file and determine if this is a plugin that it needs to then initialize and install as a service worker. And then in the add-ons post-process step, it will find those plugins, it discovers them and then it registers them in your browser. And actually this is actually a really nice approach for add-ons that are extensible. It's a nice way where people can extend your add-on without any effort on your part and it all just works. So as you can see, the more you know about internal workings of Ember and Ember CLI, the more features you can take advantage of and to use in your add-on. And there are a number of ways to do that but personally my favorite is to always keep this application open. It's called Dash, it's an offline documentation app. It's a really nice search feature. I have it open 100% of the time when I'm working and it's really easy to just look stuff up and it's not Ember specific. And again, there are many ways to get acquainted with the internal guts of Ember but I like this approach because you start from the public API you're familiar with and then you can start digging deeper and see how the framework actually implements something. So as a simple example, I was digging through the source for Ember Set that I discovered this unknown property and set unknown property which is very similar to Ruby's method missing. And there are actually a lot of add-ons that make use of this hidden feature as a way to intercept sets on objects. So there's definitely a lot of benefits into learning how the framework is implemented and there are always people on Slack who are very eager to help you understand the inner workings of Ember. And you never know, you might discover something interesting that you can make an add-on around. So those are just some of the interesting pieces of Ember I discovered when making add-ons and studying other people's add-ons. And there's definitely a lot more to discover so I hope I've motivated you enough to start digging deeper and maybe write an add-on of your own for your team. But stepping back from the tactical stuff for a moment, add-ons are ultimately about open source. And when you write your first add-on, open source feels really scary.  Your first add-on doesn't need to be amazing and you should at least give it a try even if it's really, really simple. If you do enough of it, you'll get a feel for it. Personally, Ember was my first introduction to authoring and maintaining open source libraries. I think my first add-on was Ember CLI Flash and I remember when I first open-sourced it I was really embarrassed by it. And if you do this even more, you become more confident and level up quicker. Open source teaches you a lot, not just on the technical side of things but also in terms of your communication skills. So as engineers, we might tend to focus too much on the nitty-gritty details and we forget that ultimately, we work with people, you know, real-life people. So sometimes our communication skills can tend to suffer. And finally, if you do open source long enough, you could be this person and write your own JavaScript framework. All right, so at some point or rather in your open source career, you're gonna get to the stage where you can no longer devote all your time, your free time to a single open source library. And in those scenarios, it's actually really important to be able to relinquish control and trust other people to step up and maintain your add-on in your place. And maintaining, if you ever have this scenario where you inherit a very popular open-sourced library or if your library becomes very popular, then you will find that it's actually very exhausting to maintain people like opening issues, they're yelling at you, they're calling your names. And it's very common to feel frustrated and sometimes you might even grow to hate working on this library because people can be quite toxic. And in those scenarios, it's really important to know when to disconnect. People will say mean things about you for sure. They will say mean things about your code, they'll make personal attacks against you. Now this is by no means normal and it's not something we should tolerate, but it does happen and again, when you start working in open-sourced, this technical part of it is only, probably have the challenge. And finally, if you do decide to start in the scary world of open-sourced, please adopt Sanver. Thankfully we have tools to make it all easier and be a good open-sourced citizen. All right, we've talked about a lot today. We first, we looked at what the major differences are between an add-on and an app. We learned that the add-on folder is the guts and the app folder is what's merged into the consuming application. Add-on hooks are really powerful, so do check them out. Then we talked about different approaches to managing the developer experience. Good documentation is really important as well as meaningful tests and you might want to take some time to think about how your add-on can be configured, how it can be extended by other people. And finally, remember that open-sourced is not just about the code. I hope my talk will motivate you to get out there and enter the scary world of open-sourced. You can reach out to me on Twitter. You can look at, look for me after the break if you have any questions. Thank you all for listening. You've been great.


Hello and welcome. In this lecture, we are going to look at the flow of control in a program with function calls. Here is a quick recap of some of the relevant topics we have already studied. We have seen the use of simple functions in programs. Basically, a function encapsulates a computational sub task and allows us to do modular programming. We have seen how one function can be invoked from another function and we have also seen that functions mostly return values of specified types. We have also looked at in some detail the contract centric view of programming with functions. In this lecture, we are going to see in great detail how control flows in a program when a function is called and when a function call returns and we will see that this flow of control is implemented through activation records and call stack. So, let us recall the encoding example that we had seen in an earlier lecture. We wanted to store the quiz 1 and quiz 2 marks of all CS11 students in an encoded form so that others cannot figure out the actual marks. The encoding strategy we had decided upon was that the ordered pair of marks m comma n will be encoded as 2 raised to m times 3 raised to n and we are going to assume that all marks are integers in 1 through 10. Here is the C++ program structure that we had seen earlier. I have only written down those parts of the program where I want to focus these are the parts with function calls. The other parts I have blanked out with 3 dots. So, here in the main function I have a loop which is iterated for every student where we read in the marks and then call this function my encode which takes to integer parameters and returns an integer value which gives the encoded version of these 2 marks. Now, the function my encode in turn calls a function power to raise 2 to the power of quiz 1 marks and 3 to the power of quiz 2 marks. So, this is another function called within the function call my encode and of course, power raises base to the exponent and returns that value. Now, in the contract centric view of programming with functions we said that we do not need to worry about the internals of a function when we are using it and this is achieved by specifying preconditions and post conditions and respecting those whenever we call a function. So, this is very important in the use of programming with functions. Let us recall the preconditions we had used there. We had said that quiz 1 marks and quiz 2 marks should lie between 1 and 10 and why did we say that? So, that the result which is 2 raise to quiz 1 marks time 3 raise to quiz 2 marks can indeed be represented within 32 bits and of course, if this precondition is satisfied this function guarantees that the return value is exactly as we expect. For the power function we had a precondition base greater than 0 exponent greater than equal to 0 and I have also added another part to the precondition here. This is important which we had not discussed in the earlier lecture that the result base raise to exponent should lie between 1 and 2 raise to 31 minus 1. This is the range of positive numbers positive integers that can be stored in the integer data type and so we require this as part of the precondition and if this precondition is satisfied then the return value will indeed be as expected. Now, let us look at how control flows in this program with two different function calls calls to my encode and calls to power. So, here is our little running man showing how the control is being executed in this function. We are inside the for loop and we have now encountered this function call. What do we do? We remember where to return back when this function call returns in some book keeping information and then we go to the first executable instruction of my encode and then we start execution from there and we encounter power. Now, this is the function call power. So, again we have to remember where to return back from power and start executing the function power the instructions in the function power and after executing those instructions when we hit return result when we execute this instruction we have to go back and look at this book keeping information to figure out where to return control to and once we have done that we do not need this book keeping information we can proceed ahead with our execution of my encode. We encounter this function call again we keep track of where we should return back come to power and start executing the instructions there when we hit result there we look up this book keeping information to figure out where to go to then this book keeping information is no longer needed and finally, we execute the remainder of instructions execute the return statement here and now this book keeping information tells us where we should return to. So, we return there the book keeping information is no longer needed we now execute the remainder of the instructions. Now, this is a for loop. So, I might go back into the for loop and execute the loop one more time. So, as you will see we are keeping track of book keeping informations every time a function is called. So, that we know where to return to when we encountered the return statement in a function and now this control returns there and we continue execution that is the second invocation of the function power and this time maybe we have put a large exponents of power is running a bit more it is taking a bit more time to run power and then after we have run power after we have executed the instructions in power we are going to execute the return result instruction and then this book keeping information tells us where to return to and then we execute the subsequent instructions return from the function my encode execute subsequent instructions in the function main and maybe this time when we go back to the for loop we have to exit from the for loop. So, we execute instructions after the for loop and return now having seen this animation of how control flows let us take a closer look at what exactly is happening. The operating system called the function main I have sort of represented here by saying that the operating system at some point of time called the function main the main called the function my encode with two parameters. So, I have sort of put that on top of the previous entry that I had kept there because this is the latest function called that happened the main code in turn calls the function power with some other values of parameters. So, now I put that on top of the previous two entries because that is the latest function called that happens. So, now when power returns I have to look at the latest function called that happened and I have to figure out where to go back to in main code specifically I will go back to exactly the location exactly the instruction where main code called power. And after that this entry is no longer needed then my encode calls power again with different values of the parameters. So, I store that information on top of the stack of information because that is the latest function called that happened when power returns to my encode I have to see what was the latest function called where was the function invoked and when power returns I will have to go back to exactly that instruction where this function was invoked and then that entry is no longer needed now my encode returns to main. So, I have to go back and figure out where did my main call my encode I have to go back there after that that entry is no longer needed and finally main returns to OS after which this entry is not needed anymore. So, if you look at the way I was managing the information over here I basically needed to keep track of which function was called, but whenever there was a return I wanted to access information about the latest function that was called. So, I really need to access information in the last and first out order. So, that is what we need to do we need to store information about function calls such that we can access them in the last and first out order, but this is exactly what a stack allows us to do you can think of a stack of papers when I put in one paper it goes to the bottom of the stack the next paper goes on top the third paper goes on top of that and when I am removing papers I am removing from the top of the stack at any point of time and then if I want to add some more papers again it again goes back to the top of the stack and removing again removes always from the top of the stack. So, this is exactly how we want to manage information about function calls. So, that is what the computer actually does it uses a call stack to store information about function calls and we will soon see that this call stack resides in a special reserved part of the main memory. So, now the question is we know that we must use a stack what is the information that we must store in this call stack. Now, let us recall the flow of control again we made a function call there and we kept this bookkeeping information here and then when we executed this return statement inside my encode we use this bookkeeping information to figure out where to come back to which means that I need to remember where to return in the calling function in addition after I have returned back here I am going to execute further instructions in the calling function. So, I must also remember what the values of variable look various local variables where in the calling function at the time I made this function call. So, this basically tells us what we must store in the stack now to understand how it is exactly stored let us see how the memory for an executing program also called a process looks like. Now, the operating system is going to allocate only a part of the main memory for use by a process. So, this is the main memory the operating system may allocate this part for use by our process and this part is further going to be divided into three segments the code segments stores all the executable instructions the machine instructions in the program the data segment is used for dynamically allocated data we will see this in a later lecture the stack segment stores the call stack that we have just seen. Now, that you know that a program is actually stored in a part of main memory. So, it is easy to see that each instruction of the program which is stored in some location of main memory will also have a memory address and inside a computer in the CPU we use a special register called the program counter that always holds the memory address of the current instruction being executed by the computer. This is very convenient when implementing function calls and returns because when a particular function is called from another function all we need to do is we need to note the value of the PC at the time the function was called we need to save it somewhere and when we are returning from the called function we should simply resume execution at the saved value of the PC. So, this is how we actually manage information so that we can figure out exactly where to return when a function returns and this is what is formalized and what is called an activation frame or an activation record every time a function is called we make an entry in the call stack and this entry is called the activation frame or record. For example, if the main function calls my encode this is the caller function this is the call function the activation record for the callee will contain memory space for all the local variables of the callee it will contain space for the program counter value in the caller when the callee was called. So, in our case it will have the address of the instruction in main that called my encode it will have space for the return value of the callee and it will have some additional bookkeeping information also let us not worry about that. Now, once we know that this is the information that is saved in an activation frame which will go on to the call stack let us see how activation records are used in a call stack. So, let us say a function calls another function in this particular case my encode calls power. So, in the call stack we already have the activation record for main this was already invoked main in turn invoked my encode. So, the activation record for my encode is also there and now my encode is invoking power when my encode when my encode invokes power a fresh activation record for power is created the values of all these function parameters from the calling function to the called function gets copied from the activation record of my encode to the activation record of power the PC value of the caller the address of the instruction that called this function power is saved here in this yellow thin rectangle here other bookkeeping information is updated and finally, the activation record of the callee is pushed on to the call stack. What happens when a function returns in this case when the power function returns its activation record is popped out from the call stack the return value of this function here we had a return result the return value was reciting the activation record of the power it will now be copied to the activation record of the caller which is now on top of the stack the value of the PC which was the location in my encode where power was called will be popped from this activation record and loaded in the PC of the CPU the activation record of the callee will then be freed up and it is an execution will resume exactly at the location given by this updated value of the PC. That is the instruction in my encode where power was called so in summary in this lecture we looked at flow of control in function calls and returns we looked at how memory is laid out for a running program which is also called the process and we saw the use of call stacks and activation records in function calls and returns thank you.


for the future, and I assume the card has this on their agenda, but it seems to me that two big questions for the African rice sector moving forward is, are you going to favor large farms or small farms? Are you going to try to go with 50-hectare farms with this core management input, bringing finance and basically turnkey operations that can produce high yields reliably with good access to markets and good information? If you like a plantation approach to growing rice, or are you going to do this through the existing network population of very small farmers who are under-capitalized, who have very little knowledge? There are good rice farmers in Africa, but most farmers in Africa do not have much experience growing modern high yield rice grains. So the first policy question is going to be, are you going to push this infrastructure investment and development in favor of a large farm sector, or are you going to try to figure out a way to get this to small farmers? Prabhu's speech and the line at the World Food Prize in October said, so small farmers can do this. I believe that small farmers can do this. I am not at all convinced that African governments can do this. They have not shown a whole lot of skill at bringing small farmers into a highly productive farm market private sector driven economy. So that's going to be a real challenge. That's our goal. Then we need to figure out how to talk to governments about getting small farmers productive into the system. Second point, I'll quit then. Are we aiming primarily at increasing rural rice consumption through production in local areas by small farmers for subsistence, or are we aiming primarily at the rapidly growing urban rice consumption much of that supply by imports? And so we would see this as an import substitution approach rather than a subsistence approach. I understand that you've got that question on your agenda. I would love to see you do both, but my guess is that resources are going to be scarce. Policy attention tends to get focused, and so I think you're going to have to face that one way or the other. I was going to close by talking about all the problems with the rural rice market and the facts, the instability and the unreliability of that market pushing Africa to improve its own rice productivity simply as an insurance mechanism against being dependent on a highly risky, not untrustworthy and unstable rural rice market. Much of my time out here in the last couple of years, and I expect the next few years, I'm actually trying to make the rural rice market more stable, more trustworthy, more accessible, and so I'm actually hoping to solve some of your problems from the outside rather than from the inside. Let me stop at that point. Thank you. Questions? I can see still the pessimism about Africa, and whether or not it is effective to have a price for it. You're tough, but I won't say it's pessimistic. They're just tough questions. Yes, and we'll pay attention to that as I said earlier that that book has shaped the opinion and the policy of many organizations. I think I will now open the floor for debate. I guess I'll put forward some of the questions that you have raised on this whether or not Africa will be consuming 100 million tons. You say no, that will not be the case despite the growth. Why not just lie and try it? What's wrong with that? But still all the answers, and also you say the technology is there, but there are other which are not there and I wish you don't think that it is going to come so easily. Infrastructure, a milling especially, irrigation and then also policy. And what should be the strategy whether it is trying to import to JF, import substitution for the human consumers or focus on the workers. I think those are very good questions to start our debate. We have our first speaker who left because he had to go to America. We are two speakers and also I think there are many now who know a lot about Africa. So I will take two and I will start with Sir Andrew. Sir, can you hear me? Yes. Let me start where people have thought and that is that the two, the world's two largest importers of rights are Nigeria and the Philippines. For all the same reasons, the Philippines would like to be self-sufficient in the rights of the void, but that's not going to happen either and it's not going to happen in Nigeria. So we are sort of in that but there is one other thing that we haven't discussed and that is Asia is running out of water and you need water to produce rights and there is something called virtual water which means you go to where the water is and there is also something called there is a little bit more negative called water graph or land graph. What you need to think about is what is China doing in Africa? First of all they are building a lot of infrastructure but it's not rice mills but they are building roads they are doing a lot of things in Africa to help them to build infrastructure. You know, a few months ago Bob Singler was invited to Saudi Arabia and I think he thought he was going to get some money from the Saudis but the Saudis wanted advice about where to grow rice in Africa and so you have a question and you know when the Chinese grow rice in Africa they don't grow it the way the Africans do they grow it the way the Chinese do and they hire a cheap laborer and I don't know exactly what they do with the rice once they get it grown whether it goes back to China or further at least the large army of Chinese are now working in Africa I'm not sure I don't think it helps the African countries to develop their own rice because the technology they are using is not the kind of technology I think that small African farmers need to use so I think that what I'm saying is that somehow this needs to be put into the equation of where is the future for African rice I'll take few more questions I usually agree with Peter I'm less pessimistic than he is and Peter you were not here yesterday when I made a comment on the very question you brought up which is how much rice should Africa import relative to domestic production and I think it's not an either or issue we all agree with that and I just want to put some numbers on the table I happen to know these numbers because I just looked at them while I was bored on the flight right now approximately the demand for rice in Africa is close to 30 million give or take no mercy no mercy right now the total cultivated area under rice is around 5 million hectares so let's take an average of 2 tons per hectare you've got about 10 million tons that's coming out in Africa today and with a little bit of effort you can make that 3 tons right so you're going to get about half of your requirement with a little bit of effort with quite a lot of effort you can make that 4 tons and get a significant share of that requirements coming out of Africa and much of that is going to be for areas where consumption is more low etc and you still have urban populations in cities like Lagos etc where it makes sense to you I don't think there's that level of strategic discussion taking place around rice in Africa I think much of the discussion around rice in Africa is should Africa import should Africa produce its own but we're not taking we're not opening up the map of Africa and saying where can we increase productivity and what's the cost of doing that etc and I hope card can do that you know we're trying this from the Gates Foundation side but it's really important for people to take that broader perspective the second question and so that's not a question it's a comment that's not card which is the South-South cooperation which you've got is really useful I'm wondering why some very important players in South-South cooperation are not in card and should be there in your list you don't have China you don't have India you don't have several other countries who are big players in rice and these countries are doing terrible activities which is outside of card and I think at this stage getting everybody into the same hand is better than people I don't think either of them are questions


Welcome to ITU studio. We are in the Walter Communications Development Conference here in Kigali. We have the honour to be with Honourable Minister Napa Moses Naoum from Tanzania. Welcome in the studio. Thank you so much. Thank you. Yes. How is the government of Tanzania creating an independent environment for digital transformation to cope with the fourth industrial revolution? Thank you very much for the opportunity to come and join you in this important session. Tanzania is one of the countries in the world. We are moving towards doing digital transformation in the country. We start by putting the legal framework together, having policies, laws and regulations that will enable fast digital transformation in the country. We are reviewing the laws. We set some policies together to help this transformation. But also we are doing some investments on the infrastructure because it is also important to put the infrastructures together. You can have the legal framework but also the infrastructures. We built the ICT broadband backbone and you might be knowing we are connected to seven other countries. We are putting the infrastructure in the country but we are also connecting other countries. Thirdly, we have put some institutions together so that we have the legal framework, the infrastructure but also the institutions. We have formed, for example, the universal communication services access funds to accelerate reaching to the rural because we need to connect to the rural together. So all these together, they create a conducive environment for digital transformation in the country. Given the theme of these WTDC, connecting the unconnected to achieve sustainable development, what are the specific initiatives in Tanzania which are being taken to ensure that everyone is connected? One, as I said, is making sure there is a proper legal framework to allow accessibility to everybody. Two, to improve the infrastructure, the communication towers, especially to the rural. Connect to the schools, for example. At schools we put emphasis on helping especially the girls and the disadvantaged groups. Connect to them to access the internet but also most of the developing countries, our people have got problem in having devices, devices that will make them connected. So in our country we are now reviewing how do we subsidize helping especially people from the rural to have the devices, the smartphones, the tablets, the iPads, that will help them use the internet. We have a good number of people who have access to the infrastructure, legal framework set but they don't have devices. So we are talking with telecom operators to see how they will help their customers to have these devices so that they can access internet and this will help them to be connected. Honorable minister, would you please tell us how your ministry do just to ensure that girls, women, young people are not left behind, especially also the marginalized people? First of all, to us connecting our people, access to internet is one of the human rights. And if it's one of the human rights, we need to make sure that no one is left behind. So how do we do it? As I said, we invest. If we do the investments, it will help to have the infrastructure ready for them. Then we put centers that will help the disadvantaged group to access the services. And especially the girls, as I said, people with disabilities, the women. For example, in our country, things like financial inclusion using mobile money services is really peaking and most of them they are women. And girls, they access these services and you know, with accessing these services, then you include them. You make sure that they are not left behind. So we bridge the gap by making sure the services are available to the environment. And we put now the legal framework to allow them to participate in the connectivity. Thank you very much, Honorable Minister. Thank you very much. Thank you for your time.