Hey guys, so we're talking about data-driven product development, and I want to jump in right. And I want to start off with how product development actually happens in general. When I say general, I don't mean a large-scale company, maybe like something like Google, but something like a traditional startup or maybe even a mid-scale startup. And how do these companies do product development in general, right? So I've been working with a few startups and what I've seen is that it's to a large extent it's hunch-based, where let's say a project has a very prolific product manager, right? He's been working for some 10, 15 years, so he gets to call the shots on what gets added to the project and what doesn't get added, right? Or maybe it's a developer who has been at the company for a long time and then gets to do the same, or maybe the designer, right? You get the drift. So it's probably someone in the team who is probably the most senior and supposedly has the most amount of experience. They say that this has to be done this way, it's going to be done that way, right? So there's another point that I want to specifically call out, founder-first. Hunches can also be founder-first because every founder likes and wants to be Steve Jobs, right? Where they call the shots and they can define what the users are going to use. They want to do that, but there's a very high chance that you guys sitting in the office have a disconnect with the audience. Maybe if you go out, have field trips, talk to your users, that's the thing what you're supposed to do and then take a call, right? But what if you're sitting in your office and defining that this is how the users are supposed to be using the app? That doesn't really work. And founders, they love to do this. They want to be seen as these product gurus, right? So that's a lot of this. It's also reactive. Somebody before my talk spoke about this also, that maybe you launch a feature and you get a lot of angry responses on Twitter screaming, hey, this is not working the right way of expecting this or you have a lot of people shouting at you, maybe even writing to your support tickets and everything. And then you take a step back and like, okay, what just happened? And then you probably have a look, make changes and make another release, right? But there is a high chance that your product doesn't work the right way and nobody told you about it. Your users are not that engaged and they didn't get you to get back to you on this, right? So product development tends to be reactive in the early stages a lot. And when they do look at data, most of the companies tend to just end up adding something like a catch all system, which is like a Google analytics, which what it does is like a magical script that you put into your HTML page and it starts tracking your users, how they're going from one page to another, how many users dropping off in between, it gives you all of that data, right? So a lot of people start thinking, okay, we have data. We can always look at it whenever we need to. And we are done. Let's just stop at Google analytics. Then if somebody realizes, okay, probably we need to be doing a bit more in terms of analytics, we need to put in a lot of custom tracking. It gets pushed off because of lack of bandwidth. Most startups tend to work in a crunch mode. As a product manager, you always think that there are not enough developers available for all the things that you want to be doing, right? So lack of bandwidth defines to a large extent how the products are going to be run. So yep. So this talk is about data driven product development and how you can go from these stages to a more data driven approach where you have the data talking and data analysis being the major way of making things. And who am I? So I'm Shashank Mehta. I take a lot of roles at Razor Pay. It's an early stage startup. I was employee number seven. So I'm primarily now an Aalakartian manager where I'm pushed to handle whatever requires handling. I've done a lot of other things which helps me in taking a very holistic approach to the product. And that has helped me. But at the same time, it's difficult for me to tell you guys what exactly I do on a day to day basis. Apart from this, it's relevant to this talk. I've worked at a company called Zomato two years back where I made a product called digest, which was entirely about collecting statistics from users, what was happening and then comparing it to the past. So this tool was also made by me over there. And yeah, so some of our friends are pretty excited about this and they've their own hashtag. Feel free to give me feedback via this hashtag. I'll be monitoring. You don't need to remember my Twitter idea or anything. Just to eat a Mehta refresh to the extent that I think folks, I think have a different timeline for Mehta refresh also now. But anyways, yeah. Okay, so now you've decided that, yes, let's let's bring in data. Let's make this entire approach more scientific. Let's. So yeah, you will be like, let's define data points. Right. First step is very simple. Define data points. Nope. Uh, today in the morning, the first talk was by Sovik and he mentioned how before making anything, making a content website and the entire IA thing, he said that you should be asking the right questions. And what I believe in analytics and analytics also write questions are the most important thing because the data point is just a metric. You need to be asking questions on how the users are going to be using your product. You need to be asking questions on if let's say people have a problem, what data do would I already need to have to solve those issues? Right. And you need to also ask questions. Okay. Will this feature work as expected? And you need to define the expectations. For example, how do you call a feature successful after you've released and people started using it? What is the metric to define a feature as successful? Or the corollary is how do you define it? The product has been an absolute fail that we released it and turns out it's a flop. We were absolutely wrong. Right. So you need to have definitions with these things and can these be quantified? Uh, just saying that, okay, if people are happy using it, it's not enough. You need to have some numbers and that's very important. Going forward, right? The question that I just set out loud over here. These are questions which anybody can ask about any product. The very generic, but there are a lot of questions which can be specific to your own product. For example, with Uber, Uber might want to track the time that it takes to open an app and then book a ride. Where are the dealers? Right. It's specific to their particular app. So you should be asking questions at all points of time. And before making any particular thing, any changes always ask questions along the lines of these, but at the same time, whatever is required for your product, ask those questions too. So now that you're done with the questions, then you probably move to define a data points. You could be tracking the events, user clicks, you could be, for example, in Facebook, you could be tracking the likes and how many people open their own profile page, et cetera. You collect data.  I've mentioned Google analytics. There's mixed panel, there's segment, there's key, there are a lot of different things that you can use. Then you analyze. Maybe you have a product manager or maybe if you have very copious amounts of data, you have a data analysis team which looks into it and then gives you meaningful insights into it. Then you iterate. Products are made with iterations, right?  And finally, what are you supposed to do profit? This is all too abstract and it's way too high level. So I'm going to be looking at an example. Instagram stories. So how many of you know what is an Instagram story, the feature? Okay. So I knew there would be some people who would not know. So Instagram stories is basically Facebook's take at Snapchat. Basically they decided that, okay, maybe teenagers don't want to be posting photos which last for a long time. So decided we'll have a system where you can post an ephemeral photo or a video. It stays up for 24 hours. People who are following you can see it and then it goes away. It's not available anymore at all. So how it works is on the top that you can see the plus button on the top allows you to, the plus button on the top allows you to post photos or videos. That button is specifically for the Instagram stories. The button at the bottom that you have, it's for the normal Instagram account. You can keep posting throughout the day. It gets added to your 24-hour timeline. And on the top that you see over here are the stories from your friends. So they're listed over here. All the friends who've been posting stories, you can see it over here. And when you go inside a story, the white bar on the top, these four bars, these show you how many posts are there in a story. You can actually draw on a post. You can add emojis. You can actually send messages for a particular, like, I like this photo. So I can reply back, hey, a nice photo, really creative, maybe. And you can, there are a lot of gestures. You can actually tap left to go to the previous shot in the story. You can tap right to go to the next. You can swipe. A swipe gesture skips the entire user. So there's a lot of gestures. It's like a standard mobile product where you have gestures, you have actions being taken, you have consumption. So that's why I'm taking this example because it has a lot of the general thing that you see in an app. Right? So let's start asking the right questions. Same questions. Success, failure, define what is expected in everything. And, yep, let's start with defining success and failure. Right? So I took a lot of examples, especially for this talk and at work, I take a lot of products. The way we define success and failure, I've noticed that there's a trend. It can vary from product to product again. But the trend is basically first you define the number and type of users. The number of type of users who are going to be affected by this feature or this product. It could be your daily active users. It could be your monthly active users. It could be a segment. For example, only your power users or let's say it's only for teenagers from the age of 13 to 18. You define a segment, right? And then you quantify what is the effect or the effect on these users. How are they going to use it? So you define all of those things. So I took a shot at this for Instagram. You can vary, but yep, this is a definition that I want to take for Instagram that success on a normal day, if let's say 85% of active users post at least three shots and view at least four stories. It's a success. It's a proper success. Your product works exactly like how you would want it to work and everything is fine. The other side is the failure where on a day less than 50% of active users post less than three shots, you less than three stories, right? How I came to this is I so since I am not working with the product I took a guess that for Instagram, they want stories to be the next big thing. So they want at least 85% of active users to start using it and between these two definitions, your success and failure, there's a lot of space and there's a very high chance that your product might actually lie in this space. But that's a good thing. If you have already defined this and you know that it's lying in between, this is where analytics serves you the best because now you can know that, okay, my metrics are at this level. What can I do to push it up? The usage, the events and everything is telling you that it's at this level and now you have to push it up. That's your next role. So let's see some data points for Instagram, right? We have already defined success and failure, right? So for success and failure, all I need to track is the number of stories viewed, the number of posts in the user's story. So I'll know how many stories he has seen and I'll know the number of posts in the user's own story, right? So this would help me in judging success and failure entirely. Pretty simple and straightforward. But that's not the kind of analytics I'm focusing on while it is relevant and to the point, but that's not the analytics I'm focusing on. And my entire focus on this is that a PM or maybe even a designer and developer, when they think about the product, they have to step out of this data points and move to something that I would like to define as ephemeral data points versus the database. So when I was working at the Matto, the tool, for example, what it did was it looked at the number of likes that a user's post has got, a number of photos that are user on average post. This was a metric, right? This is in your database. It's already available and stored in your database. Right now, if I make this product, which I did for the Matto, I could actually add the last five, six years of data without requiring to make any changes. I already had historical data available and that's key because you have all of that data available. You can actually start it whenever you have the time to do it. But what you're missing out on is something that I want to define as ephemeral data which exists somewhere inside your ecosystem but it's not in a database at all. For example, at Zomato the number of times the number of pages maybe I scroll that data was not available in the database, right? Or maybe inside the Instagram stories the number of times a user gesture it's not available. It's there inside the application. My Android app knows that the user took a gesture but it never got added to the database and this is the data that I can never look at afterwards. Right? So these are the main points of focus that you should always look at and see that how do I start tracking these things right now so I don't miss on this data. So what are the ephemeral data points that can be there for Instagram? Time taken to post a photo in a story. So your feature, so you want it to be the main feature but if there are a lot of huddles in the way of the user before he can post a story and post a particular thing, there are going to be issues. So you can track the time it takes to go from an app opening to the user posting. Then there are multiple things in this. You can look at how much delay was added due to the interface itself, the interface that we have designed so carefully. How much was the delay? If it's too much, it's an issue. Right? And then there are delays which maybe are not in your control or maybe to an extent like the network delays. So let's say the network delays tend to be a bit too much and especially let's say in India because the internet is not very good, right? Maybe Instagram needs to focus on the entire process of minifying the photos better, maybe making them lower quality or do something that can push the number to the success levels, right? But you need to be tracking all of this and these are some points which are not easily available to you guys. Then the days before posting first have a story.  If you just look at the database you would know that the person posted a story on let's say the 10th day after the release but you don't know when did he start seeing the feature. He could have seen the feature on the 6th day after the release, right? This data again is not available in a database may not be, can be depending on how you have structured it but it may not be available, right? And this matters because this for example in this entire thing, the amount of time I need to spend or a user has to spend before he gets convinced to use a feature is important because this is something that you would want to control. If a feature takes about 30 days for someone to be convinced to start using it, it's an issue, right? Again, this is a point which is not available to you in the database. The number of stories I view before I am convinced that yes, this feature is right, I need to start using it. Again, this may not be available in a database. Some more points. I spoke about gestures, right? On mobile especially gestures are the way of how people interact with the apps. No longer are these guys crawling a lot. There are a lot of gestures involved especially with these high consumption media applications. Gestures are the main thing. You look at a video app, you look at a photo Instagram app or Snapchat. Gestures are the main thing. To be very honest, I have been using Instagram stories on a daily basis and to me it was very intuitive. But my friend Nemo, when I was speaking to him about these slides, he told me these gestures exist. I had no idea. Right? So that's another point that we have not been tracking and has been missed. So how can you track it? The number of times the gesture is used, you can track the total stories viewed before I did use the first gesture, right? These can help you in then analyzing it and we'll get to the analysis part. Then for example, did the person use the drawing feature? Did he use the writing feature? Did he send a message? So all of these points should be tracked and they help you in understanding how is the user really using the feature? Now, these are not covered by your high level metrics and that is why these tend to be a bit more important also. So you start collecting data. Now that you have defined data points, you have to start collecting data and while again, I don't work for Instagram so I'm not sure how exactly they would do it. But we have our own entire pipeline at Recipe and I'm going to just run you through briefly because my focus is not on the tools. There are various tools you can use, whatever is more convenient for you or what your company is already using maybe. My key point is to tell you that there are a lot of things that you can do. For example, Google Analytics is used by us for the general catch all what we don't track ourselves. Mixpanel is for a lot for segmentation, for custom events, for creating funnels, all of those things. Mixpanel helps me identify what a single user has done. Whereas Google Analytics works on the aggregate data. Keynotio is a special one. Not a lot of folks might know about this. Keynotio is to a large extent similar to Mixpanel but there's one key difference that they give to people like me who are also developers. I can use the graphical interface to create an entire query where I'm defining a segment and I'm defining a metric and I'm asking about the historical data. Keynotio, what it does is it also gives me an API endpoint complete the token everything that can copy paste to my application and I can query that data whenever I want in a programmatic way. Keynotio is used for that aspect in our company. I can give you an example also where we have a checkout form where a merchant so RazerPay is an online payment gateway so we help merchants collect money. If you use Hasgeek and bought your tickets, you bought it via RazerPay. Over there we have a merchant icon in between when we were changing the designs how we were displaying that icon was being changed and we could have easily broken it for our older customers who were using it in a very different way. So what we did is we went back to our Keynotio data ran a query which got us the unique images, got an endpoint and then ran it through the new design to see how is it working. That's how we did data driven development and the last one is special one Lumberjack. It's a custom service that we've made very simple nothing very complicated. All it does is it takes the data from all of these different sources and puts it in a normal database so that they can run our MySQL queries and other querying whatever you want to do so that we're not just curtailed by what features these other applications provide us. And how all of this is wrapped up into one is segment.io. Segment.io is a pipe which allows me to send data to all of this. So analysis right. Let's look at the look at the gestures example again. Gestures supposed to be useful and they're supposed to be intuitive. You can look at the data how how frequently is a gesture being used. If it's not being used at all by a particular user it may mean that it's not intuitive right. And this is when you can take a product call based on the data that okay it's not intuitive. We thought it would be intuitive. We need to do something probably we can call it out specifically or we can probably you know if the user does not use it till 6 post then we show it up. You can take various calls and that is possible if you're tracking it and it's again on the ephemeral data we would not have been working on this if you were not tracking this ephemeral data point right. This is just an example. Your analysis depends on how your product actually works itself. And then the many steps are the same. You iterate, you track, iterate, profit right. We're going to move on to some other examples now from Rezape. So as I said we're an online payment gateway company the most important factor for us is success rate. So this is an example live data for a particular merchant. This merchant is getting about 88.05 percent success rate at an order level that if a customer is trying to pay the odds of successful transaction are 88.05 percent. Big Spanel helps me to check it at a merchant level at a merchant city level. All of those things. It allows me to look at historical data how the trend has been in the sense that I can look out there some days when it was as good as 100 percent some days it went down. We can have a look at why that happened. Then there are other cases for example over here what I'm tracking is that for a payment there are two end scenarios success failure and we had programmatic callbacks given to merchant on success and failure but in Android what we observe was it wasn't happening 100 percent time. And in hindsight it was obvious user can press the back button and probably just press the home button quit the app not taking any other step right. So we started tracking these the first part that you see over here is the number of people have submitted the data to make a payment to be a car details then the second one is the number of people who press the back button the third is how so we now show an alert that hey are you sure you want to cancel a payment. So the third one is when the person said yes I'm sure I want to cancel it and fourth is when they went back to the checkout right. So this helps me in analyzing a lot of things and I can now test on this for example if I change the alert message what are the implications. Does the number in between change those things can be done via this. I'll take another example so auto to be filling is a feature where it's on Android where if you're making a payment to read your SMS show it to you over here you click on use OTP and it's done. So let's look at the number of users in this for us it's everyone on Android the usage and effect the success rate and the time to pay right. These are the metrics that are going to be affected and this is the metrics that we took we have to reduce the time taken to complete a payment by 30% and increase success rate by 5%. This is not a critical feature in terms of the payment itself if this did not exist you can still make a payment. So this is an add-on right so for us an increase even in 5% success rate is a big number and failure over here means any decrease any decrease at all in success rate or increase in time to pay even milliseconds becomes a failure because this is not a critical feature right and this is what we found the success rate increase was actually 8% during the time and we did the analysis and the decrease in time to pay was as much as 45% that after the 3D secure page open initially it used to take people 30 seconds to switch to another app look at the OTP put it in and then submit it after this feature it went down to 16 seconds right that was a success for us but there were issues if you look at just the success and failure metric there were issues because that clearly said it's successful what we observed is that in the feature what we had is we had an overlay on top because you wanted the focus should be at the bottom and we were expecting that if let's say something happens the OTP is not delivered user would just tap on the overlay go to the bank page and take an action like ask the bank to send the OTP again and answer the payment turns out 10% of people did not realize it's clickable and you could find this out because at a payment level what we saw that the back presses had increased suddenly and that's not one of the things which we were adding to a success because overall it was looking like the increase has been good enough we had 8% success rate but turns out it could have been even more than 8% because of this issue so we went to this where we removed the overlay completely and tried to bring prominence via shadow so this is another example of an iteration that you can take if you're calculating and you're tracking ephemeral data points so you have your entire system in place what are the new possibilities that are now open to you when you've done all of this you can now tell precisely if your feature is working how is it working what are the actions that the user is taking but this opens up a lot of new possibilities in terms of the experiments so in the instagram thing on the top what you see is the stories of friends right it's in some particular order it has to be an order right can we actually play around with the order to see how the metrics are being affected does the order of friends in that list matter what if I have a look at ok this person likes why person's photos more so let's put why on the top does that affect the time it takes for a person to convert to an instagram story user does that how does it affect all of these metrics right so you create a base and then you open up your application to a lot of experiments like this if you have the entire base in place a lot of other things that instagram could probably do like notifications if one of my close friends starts posting does this affect my adaptation of the entire feature and when I'm clicking a normal photo so as I told you right there's a different button for normal instagram a different button whatever I'm clicking from the normal button I show a small overlay saying hey do you want to add this to your instagram story does that really engage users so you can do a lot of these experiments and it's only possible if you're tracking all of these data points I just want to call out unsplash.com all my images background images are from there they are creative comm and zero license requiring no attribution but thank you and yep that's the end of my talk I'm going to leave this slide over here because this talks about how PMs generally work a lot of misconception about how what product managers do and yeah I'm open up to questions now thank you yeah great talk thank you you were specifying that lumberjack is used for collecting data of all the other analytics tools into one place segment yeah so how is it different from segment warehouse I've not used the tool so I can just explain to you what segment does what segment so the major advantage of segment for us is that on android where you cannot keep on changing the services right so segment becomes the one endpoint and I don't need to change anything on the application to add another service so I'm not sure the other two probably that works the same way but segment allowed me to I can remove keynote I have put another third party service ahead of segment without requiring any change in the android application that I've released in the market so that's the major advantage for me alright I guess either I was clear or I have a question so I mean all the experiments you did how important or how much did you AB test versus you know just pushing out and testing the metrics so AB testing is a different setup in itself AB testing what it means is you just roll it out to 50% of people and 50% of people whereas what I was talking about over here is a conscious change in the product that you're making and then you're looking at what are the changes in metrics AB testing can come after this that if you have all the metrics in place now you can the next step would be to set up an AB testing platform where you can now serve users different views based on the segment that they are in and then track it so the entire process remains the same AB testing is an add-on to this entire feature so yeah the uh full-on to that is so once you do this right there can be another random event that can affect your metrics when you're measuring at different time points rather than through an AB test so that does it yes AB testing captures all of those things because uh it looks at the general like this entire thing what it does over here what you've done is we have added one particular feature and then looked at okay there's one particular feature that would affect it AB testing helps you in that uh so yeah that helps but over here this becomes the main base because without this I can't get AB testing in place and that's the next step for me also in uh at raise the pay that we want to put in AB testing in our main checkout form see at the larger scale what changes that's the next step for us yeah all right folks thank you is more question it's fine I can hear you I'll repeat out the question for the audience it's a pretty good question uh so what she wants to know is how do we come up with the numbers in the success metric and the failure metric itself so what we've been doing and how I came up with my own product is basically so we've been developing the feature we use it internally right uh you've rolled it out basically to our internal folks so we have like two versions of our application one is for the external people to try other is an internal lease we do we roll it out over there people can have a look and then we see what are the numbers looking like now this is a controlled environment because the people that I've rolled it out to are all people of my office with very good internet and everything so that tells me what probably the upper limit can be that it's been coming up with the metrics the second thing that a lot of people can do and we also want to be doing is uh I think one person before me spoke about this coffee house testing so you you basically go out give out a voucher and ask the person to use it and see how what happens over there this helps you in placing at a very small level that okay this is the change that can happen then you define this entire success rate and then you roll it out to everyone see okay to the masses how is it working so you have an expectation which is why a controlled environment which is your old colleagues and everything and then you move on to the entire audience and see okay how is it working at a at a large level thank you


Hi, I'm Matthew coast head dating coach and founder a commitment connection calm and today We're gonna talk about how to talk to a guy So if you're struggling to figure out how you should be talking to guys, then this is for you So first let's talk about what you shouldn't do. So let's talk about what doesn't work So one of the big things that doesn't work that women do all the time is they try to do guy topics, right? Like I get women that are like, hey, I don't want to learn guy topics to talk to guys The great thing for you is that you don't need to learn guy topics because guy topics are not Attractive, I mean it can be like a plus, you know if you can talk about sports and the guys into sports It can be a plus if a guy's not into sports, then he definitely doesn't want to hear about sports from you And here's the thing though Even if he enjoys talking to you about sports and you're into sports It's not something that he's going to be attracted to you for it's just gonna be an addition So the second thing is talking like a guy so a lot of times women will like put guys down because they see guys like putting each other down all the time and That's not attractive at all. And if you do it a lot that can be really unattractive. So I Mean if you do it once in a while, it can be cute But it's just if you're like guy they call them guy chicks like women that that you know talk like guys They call them guy chicks guy chicks only attract feminine guys And they usually end up in the friend zone with most of the guys that they like So if you want to guy to like you avoid talking like a guy Next is relying on commonalities commonalities can be a really good thing to build a friendship but and it can be a good thing to have a conversation about but don't rely on those topics to Get a guy to be attracted to you because he's not going to be attracted to you might feel closer to you as a friend It could bring him closer to you in a relationship But he won't be attracted to you for your cup for commonalities. So just remember that and the last thing that you don't want to do is Place expectations on them and a lot of women do this all the time and it's really painful for everyone involved and that's trying to get a guy to respond a specific way when you talk to him and Like getting upset when he doesn't respond the way that you want him to respond. It's just so unattractive I mean it is really really unattractive and it could ruin your relationship. It could ruin your chances with a guy So just avoid the whole expectations thing all together. Just let go of it So what does work? What works is telling stories stories are really really powerful and they can connect you with a guy They can connect you with this heart. They can make him feel All kinds of powerful things towards you They can help you capture his heart and make them just fall in love with you And so the things that you want to talk about with stories are one your values Right so find stories that convey things that are important to you in your life. That can be really powerful.  So like the nurturing or caring side of yourself that can be just so powerful and subconsciously even if a guy doesn't recognize it consciously subconsciously he can He'll hear that story and he'll think about how How he could see you As being a life partner to him because of that feminine side You'll see that polarity and he'll experience it and be like, wow, that's really cool And it can put you in that relationship category for him So the second thing that you'll want to talk about is his passions, right? so figure out what he's passionate about and a lot of women find that it's hard to get guys to open up Usually if you can get him to talk about his passions, he'll talk about that forever so just get him talking about his passions and That can be incredible I mean just really really attractive for a guy to just start babbling on about his passion sounds ridiculous But it can be really really attractive for him. He'll feel closer to you more connected to you If he can feel open about being able to talk to you about his passions and then the last thing is talking about fun and exciting things that you're going to be doing and You know this goes back to having an interesting life, you know men are attracted to women who have exciting lives and You know a lot of times I'll get women who say things like I don't want to Start doing those things until I find this partner Well a guy is going to meet you and he's going to look at you And if he's the type of guy that wants to do those things and he sees that you're not doing them yet He's not going to be convinced that you want to do him And he's not going to be convinced that you're the right woman for him But if you're already out there doing those things doing exciting and cool things and you're talking about him and talking about doing them In the future then he's going to be a lot more attracted to you and want to be a lot more involved in your life So that's it for today if you want more information on how to attract mr. Right into a committed Lasting relationship make sure you go to my website at commitment connection calm and take my quiz I'm Matthew coast and I'll speak with you again soon


Hello everyone. First of all, thank you for waking up on a very cold and early Sunday morning. Thanks for coming here. I appreciate it. My name is Thiago da Silva. I'm going to be talking about an object storage system called OpenStack Swift. I work for Red Hat. I'm a Swift core reviewer, meaning a group of people that review and maintain the code and merge code. And I've been working on Swift for about four years or so since 2004. I thought I'd start with a brief introduction into object storage in general. Like what drove the need for object storage, talk about some of the use cases and what requirements those use cases lead to. And then dive into Swift, look at the functionality, do some overview, talk about the architecture, and then just answer some questions. So it's going to be pretty intro and brief. So we've all heard a lot about the explosive growth of data that is just being generated. There's been a ton of statistics about, you know, the exponential amount of data that is being generated. And what's interesting about that is that growth, data is being generated a lot, but the rate of that generation is also growing. So it's really an exponential growth. And the second point that's interesting is that what's driving that generation of data growth is mobile applications and web applications. When you talk about data growth, you need to also talk about what types of data is being created. And I try to break that down between two types of data. What I call structured data, and that is data that is organized in a relational form. Think of, you know, really databases, right? It's data that is easy to analyze, easy to query, typically, you know, in a column and rows and in a very tabular form. Very easy to consume and analyze. And we have also what is called unstructured data. So that's data without any structure or any order or schema. Your typical example of that is all the media files that are out there being shared across the web, document files, research files. Think of, you know, from x-rays to, you know, even down to JSON files being shared across the web. What is interesting about unstructured data is that it makes up about 90% of the generated data that is being generated today. When you talk about types of data, you also have different types of storage systems for storing different types of data. We all know very well block and file storage. You have block data that is, you know, divided into chunks of blocks. We know how it's accessed, it's really well understood. File systems, again, very well understood. And you have object storage that is just a logical architecture that is used to manage data as objects or blobs of data. What's interesting about object storage is that when you talk about an object, that object contains the data and the metadata about that data, and it usually contains a unique ID. How you access that data is through a unique ID. So it has a very flat address structure, for example, compared to file storage where you have directories and you have files. Object storage typically is just a very flat, maybe you have buckets or containers to put your objects into, and that's pretty much it. The way you access it is through its unique ID. And the other point that is interesting about object storage is that differently from block and file is how you access it. Typically, you access the object as a whole, so you're either writing a whole blob of data or you're getting a whole block of data. Again, comparing, for example, to file where you might be able to open and append and write parts of it and read just parts of it. Typically with an object storage, you put and you get the whole thing, the whole blob of data. The other distinction that I wanted to make here that I think it's very interesting is that with block and file, you have local access so you can think of your data drive, your local hard drive, and you're accessing it locally. Through, for example, your file system, you have fast file system that are you accessing locally, or you have remote connections to, like your samba share and whatnot. But with object storage, what's distinct about it is it's always remote, right? Typically, you don't access an object storage through a local connection. So what are these cases that are driving the need for object storage? The first and foremost, the typical one that you see are the private clouds, right? So the object storage market was pretty much created by Amazon S3. But today, there's many public and private clouds out there that are running OpenStack Swift. I tried to list just some example of them. These are all companies, you know, OVH is based here in Europe. They've spoken at many OpenStack conferences talking about a very large cluster that they have, running OpenStack Swift and storing a lot of data. What's interesting about this use case is that typically, if you are maintaining that private cloud, you don't know what kind of workload you're dealing with, right? You're just providing a service and your users can be very varied and you don't know. But there are other use cases, too. You have what I called web and mobile applications, for example Wikipedia. It's an example that we always talk about where all the media content in Wikipedia is actually stored on a Swift cluster. Which is interesting to think about that is that I don't think the size of that cluster is too big, but the number of users is just tremendous, right? Turkcell is a red hat customer. It's a public reference that we talk about. They are a telecom company in Turkey and they've talked extensively about some mobile applications that they've built. Something similar to WhatsApp that allows their users to send messages and share photos and share videos. And they also built a pretty massive Swift cluster and supporting, again, millions of users, not only a very large cluster in capacity, but also supporting millions and millions of users. Another use case is data archival. And what I mean by data archival here, it can be either what I like to call active or passive data archival or cold storage, if you think about it. Video companies that are producing or filling on site, they need to upload their footage so that it can be whatever they do, processed production in their production site. So Digital Film Tree, for example, is a company that talked while back about how they were filming on site in Vancouver, for example, and they have their offices in Los Angeles and they were able to use a Swift cluster to upload their data to the cloud and download that data from their Los Angeles offices and speed up how that production of the video happened. Next Cloud also has been talking here this weekend. They offer an application similar to Dropbox where you can just share files across many devices or with other people. So again, all these different applications allows you to put data on a Swift cluster. You can put it into code storage and just back up or you can actively beam sharing content. So based on these use cases, what kinds of requirements does that entail? What can we learn from these use cases? The first one is that you need to provide durability. So from an user perspective who is uploading that data, again, going back to that distinction that I made between block and file with object storage, you're really abstracting the data from where the data is being stored. I don't want to know, I don't care how that data is being stored, but I need to guarantee that it's durable. It needs to, I can't afford to lose this data. So the object storage system needs to take care of that. From a user perspective, I don't know where the data is being stored, what kind of drive, how it's being updated, how refreshed that system is, what kind of backup it does, or if it's using flash or hard drive. I don't know. I'm just putting my data on the cloud and it's to be durable. It also needs to be available, meaning I need to be able to access this data 24-7 if I have to. It cannot be unavailable. That's a huge difference, for example, again, from a lot of times even looking at the SLA for EBS on Amazon or what have you in terms of block storage on public clouds. They provide very low SLA like 99.9 compared to object storage that has many nines. It's always available. It's always being able to connect. Accessibility is really how easy it is to use your API and how accessible it is. That's another requirement that drove the need for object storage in terms of all your web apps and mobile apps and how they're accessing your data. They need to provide a very simple to use API to access that data. Of course, scalability. Nobody starts with 100 petabytes of data. You start small and you need to be able to grow. You need to be able to have that flexibility for your storage system to grow as you grow. You need to be able to grow extensively, but you also need to keep it at low cost. Companies are trying to get away from the storage arrays of old time and they need systems. That's why we have this room. That's why we have SDS. That's why we talk about software defined storage. It needs to be able to be running on low cost hardware. Based on these use cases and requirements, let's dive into OpenStack Swift and just talk a little bit about that. Swift is a highly distributed, eventually consistent, durable object storage system. It allows you to store your data safely and chiply. Talking a little bit about the OpenStack Swift community, it's an open source project. It was one of the founding projects of OpenStack. It was produced by or founded by REC Space. What drove REC Space is that they were a public cloud. They had the need for an object storage system so they implemented Swift and then donated that to OpenStack to found OpenStack. What that means though is that Swift has been in production running a public cloud for about eight years. It's very stable. The API is very stable. The system is very stable. It has a very active community. We have over 700 total contributors. We have about 20 or so active contributors on a monthly basis. One of the things, like I said, I've been working in Swift for about four years. One of the things that I always like to highlight about the community is its focus on automated testing. There's a really huge focus on CI and making sure that the code that we write gets properly tested. We have really a huge focus on how we test every single code that we put in there. As an example, I always thought it was interesting how we merge a recent feature, SimLinks, and I looked at the piece of middleware that we're actually providing the functionality. It was about 300 lines of code and look at the test and it's about 2,000 lines of tests. It's like a big difference. I think it speaks to the focus of the community in terms of making sure that you're writing good code. It doesn't mean that we don't have bugs or anything, but we focus a lot on that. It's a very friendly community. It's been a lot of fun to work on those folks. Quick overview. You access Swift through a RESTful API. It's all through HTTP verbs.  The object key, the way you access a given object is through a URL. So differently from other object storage systems where you typically put your data and the system gives you back a unique key. The user itself is who defines what that key for that object is. So the key is just a URL. You have the, like I talked about, the flat address space before. You can group objects, a collection of objects into buckets or containers. And you can group containers inside a account. And think of account more like a bank account where you put stuff in as opposed to like a user. It's not really, an account is not really a user. It's more like just a group of containers. So it's just a way to organize your cluster across multiple accounts. I mentioned already before it's a highly durable and distributed storage system. You're able to load balance your cluster and you replicate the data many times to maintain data durability. Or you use erasure coding. But the point is that there's no single point of failure. Your system can be depending on how you deploy. You know, you can deploy in such a way that you don't have a single point of failures. A interesting distinction about Swift is that it's an eventual consistent system. So it's designed for high availability and partition tolerance, sacrificing a little bit of consistency. The myth that I like to dispel about eventual consistency, that's the number one thing that I hear a lot, is that a lot of people equate eventual consistency to eventual replication. And that's not true. So eventual consistency does not mean eventual replication. It does not mean that Swift, when you put data into Swift, you store just one replica and Swift will eventually replicate your data. Because if that was the case, then you'd have a window of time there that you might lose your data. Because you might have just one copy and that disk might fail. That's not the case. Swift will always store your data durability with multiple replicas so that when a system goes down or something, your data will not be lost. Shameless plug. There's going to be another talk later today where it's actually going to dive a little bit more into how eventual consistency can actually play a really nice role into the Swift architecture. And that's when we talk about, for example, global replication. So when you have multiple data centers and you need to have a cluster that goes across or expands across multiple data centers across the globe, that's where eventual consistency really shines. Swift has a very rich API exposing a lot of functionality. I list some of them there. I'd like to highlight just a couple of them. Object versioning is when you're able to store or if you have a workload that overwrites objects, you're able to maintain old copies of that object. And object exploration is when you're able to store an object and set an expiration time on it and it will be automatically deleted for you. So the system takes care of that automatic deletion. SLO is talking about or is a feature that provides large object support.  And that limit is typically five gigabytes. And that's really artificial just so that you don't have people trying to upload using HTTP, you know, a terabyte object. It wouldn't be a good idea to do that. So we put the artificial limitation of saying five gigabytes is the maximum size, but using a feature like SLO or static large objects, you can segment your one terabyte object into smaller chunks, upload them separately and then provide a manifest file and Swift will concatenate your objects for you. Temporary URL is another feature where, for example, you upload an object and you want to provide temporary access to somebody else and you don't want to provide them your authentication secrets. You can produce a signed temporary URL that you can hand it to them. They can use to get that data and that URL will expire after some time. Swift also provides support for different types of authentication systems. Temporary URL is one of them, Keystone and OpenStack, FormPost. There's also going to be another talk by Christian today talking a little bit about how to develop your own apps and he'll cover a little bit more about authentication. Let's talk a little bit about Swift architecture. Swift has a very modular architecture that allows for the flexibility when you're scaling it out. Covered here four main components. The proxy is your main gateway to the cluster. So that's how users will send their requests and the requests are received at the proxy and the proxy will then proxy out those requests to the backend storage system. The backend storage system is made up of the account server, the container server and the object server. The account server and the container server. The account is really holding just a list of all the containers for that given account and the container is just holding a list of all the objects for that object for that container. In some matter of data, the account and container server are typically data is typically stored on a database, on disk and it's replicated properly and all that. And the object server itself really becomes kind of the most important part here where that's the service that is storing your data on disk. What's interesting about this modular architecture is that you could have those four services running in one machine or you can have them run in separate machines independently of each other. They are just web servers running or implementing the WISG interface. And the communication between them, so not only the communication between the user and the proxy but the communication between them is also through HTTP. It's giving a little bit more of the flow of the data here. So imagine for example that a user is putting an object, is writing an object. It sends that request to the proxy and what happens is that the proxy will then replicate that data. So we'll write three copies of that data and load balance and distribute it across the cluster in such a way that the algorithm makes sure that you're writing the data across different failure domains. So either the failure domain can be a rack, a node or even a whole data center. So if you have multiple data centers you would make sure they distribute your data across two different data centers or if you have multiple racks in a data center you would put in different data racks. The other distinction that I like about this slide is that you can also break up your cluster between what we call the access tier and the storage tier and it allows you to scale them separately from each other. So the access tier is going to be the proxy and it's going to be very CPU intensive. So if you need to scale out bandwidth you might just be able to add more and more proxies. But if you need to grow capacity you might be able just to grow your storage tier and add more disk and more storage capacity as opposed to having to add more proxy. So that's a really neat thing about this architecture. But you can't talk about Swift architecture without talking about the ring. The ring is really about how Swift is able to determine where the data is stored. So the ring is just a binary file that is using a hashing ring to be able to determine where the data or where an object is stored on your cluster. So that's something that you produce the ring when you're as an operator, when you're deploying your cluster and the way it's used is when a object request comes in or container request comes in. The proxy is going to look up, is going to hash the name of the object that you need ID, the URL and from that hash it can look up where in your cluster the data would be stored. So the location is deterministic by using the ring and that guarantees that no single point of failure. You know you just, every node in your cluster is going to have that ring and you can look up that information there. Another interesting point about the Swift architecture is what we call storage policies. So we have the support to store data across different data, storage rules or replicas we say. So I talked a lot about three replicas to give an example, but you could define really pools of data, kind of break up your cluster into pools of data and you might have data that needs to be stored with three replicas or two replicas or a rigid coding. You can also use this to say, let's say you know I have a very, for legal reasons or whatever this data needs to stay in Europe. You cannot go to the US for example, you cannot be replicated to the US. You could also define a pool that maintains that data just in your cluster or your data center that is in Europe. So using storage policies you can do that. And that's an operator defined role that the operator would define. From a user's perspective, the way you would use storage policies is when you're creating a container you define what storage policy that container is going to have and then every object that you're going to put inside that container is going to use that storage policy. So you could have, you know, a policy of flash drives for example, a very high performance or, you know, what have you that can be defined by the operator. I mentioned the four main components of Swift, but there's also what we like to call the consistency engine that's really background demons that are running in the object stored system themselves and just maintaining that eventual consistency. It's making sure that data healing is happening properly, bit rock detection, the updates when you put an object make sure that the container database or the account database is getting updated, expiring the objects. So I gave an example there with my little diagram when the proxy is trying to write to those three replicas and is not able to write one of them. It will actually write to another place to guarantee that durability. So it always will try to write through replicas even though it wasn't able to write to its primary location and eventually it will heal and move that data back into place. So that's all done by that consistency engine. That's it. Maybe at this point you're thinking, yes, Swift is cool, right? I'd like to contribute. We have a lot of work ahead of us. The work continues. Right now we're focusing a lot on the scalability of Swift. So container sharding is an issue that we have where there are users out there that are trying to put billions of objects inside the same container and that you get what we call deep containers and you need to be able to shard that container. Lots of small files. Again, 16-byte files or objects inside the cluster can become a problem. Data tiering is just being able to move when I talk about policies, being able to move from a three-replica policy, move your data automatically from a three-replicate policy to a regecoded policy, for example. That's another feature that we're working on. We also have a project called Humiburg that is implementing or reporting parts of the system to Golang and that's for performance reasons. So there's really a ton of work to do there. And that's it. You can chat with us if you want to or you can contribute. You can find a code on GitHub or you can find us on FreeNode if you have questions if you want to talk about. And that's it. Any questions? Any questions? Yes. What is it? The priority. So what is the priority of the project Humiburg? So again just to restate the purpose. The purpose is to rewrite parts of it in Golang and the priority I would say is very high because again it affects the scalability of the system but right now we're kind of prioritizing deep containers a little bit higher than that. So it's something that we're working on. We have actually patches out there that builds the foundation work for being able to port. And we're really just talking about the object server that we're going to port and maybe some of the data consistency background demons. So it's important. It's very important to us but there's more important work like the deep containers that we need to tackle first. But it's ongoing parallel work that is already ongoing. I thought I saw here and there. Being a corporate of OpenStack I understand it means that the release schedule, the release dates are tied with the releases of OpenStack or does it have its own cable? I don't think so. Does Swift have a separate schedule from the OpenStack cadence? I guess you can say that we do. So actually a lot of OpenStack projects are following sort of their own cadence where they're able to just release their own component and when there is an OpenStack release it kind of gets bundled together and we just tag a specific release that we did, the last release, and we say this is going to be the Queen's release for OpenStack. You actually bring up a nice issue which is Swift typically actually gets called out in a nice way nowadays that you're actually able to run OpenStack Swift outside of OpenStack. You don't need a whole OpenStack cluster to run Swift. Swift is its own storage system that you can run without any actually OpenStack component. If you have your own authentication system you don't even need Keystone. You can just spun up a Swift cluster and it does not depend on OpenStack other OpenStack components. Can I change the policy in great time? Yeah, so going to repeat, make sure that I understood your question. So if you have a three replica system or policy and you want to reduce that policy to two replicas for it to lower the cost. Yes, you can, without downtime. Without downtime. Yes, any more questions? All right, cool. Thank you.


Three reasons the narcissist leaves you. Narcissists often leave their victims. Some people may call it the discard, but that's not always accurate. Because the narcissist often comes back. They often hoover victims. So it's better to say that the narcissist leaves. But the only way to prevent this from happening is by going no contact. Otherwise the narcissist will leave you at some point. Because they just see you as an object. You're just a means to an end. You're only there to produce a desired result, to fulfill a task or function. Other than that, they have no other purpose for you. And when you're no longer able to perform, it's when they will get rid of you. And find someone else who is able to perform to the standard that they expect. Even if it's only for a limited time. It's very rare that the narcissist will leave their secondary sources of supply. It's very rare that they will leave their side piece or mistress. They tend to leave the people who are closest to them. The people who are doing everything for them. It all begins with seduction.  They promise you a future. But they don't want you to know why they chose to be with you. Because by withholding that from you, they can gain control over you. But it isn't long until they begin to devalue you. Until they begin to give you insults and put downs. Which will be very unpleasant for you. Because in the beginning, they put you on a pedestal. But now they're treating you like you're nothing. Without giving any explanations for their behaviour. So it doesn't make any sense to you. But it makes sense to the narcissist. Because they want to confuse you. That's how they sustain their control over you. But at some point they will leave you. When you are very tired and completely used up. Because at that point, they will have no use for you.  Which will leave you looking for answers. It will make you wonder if you did something. Because they left you without any indication as to what went wrong. So you're left without understanding. Which is a typical thing that a narcissist will do. Because they feel entitled to do whatever they want. Without giving you an explanation. Without taking accountability for their actions. That's just what narcissists do.  You failed them. You didn't achieve the standard that they expected from you. They don't really know why they had to leave you. They just know it was something they had to do. Sometimes they might give you a reason. But it's never the real reason. They just shift the blame onto you. And cause you to question your own behaviours. But that's not why they left you. They may think it's the reason why they left you. But it's not. They may be unaware of the real reason. Or some narcissist may be fully aware of it. Or they may find enjoyment in tormenting you. And making you think there's something wrong with you. But it's just something they use. To maintain their control over you. So here are the three real reasons. Why the narcissist leaves you. One. You figured them out. You became aware of their true nature. You understood a situational fact about the narcissist. You realised that they have to consistently provoke you. They have to get reactions out of you. They have to create drama and chaos. They have to make a public disturbance or an emotional display. You may not realise why they're doing it. You may not realise that they're trying to control you. You may not realise that it gives them fuel. But you do realise that they're trying to make you react. Which then reduces the amount of supply. That they can get from you. They can no longer get the reaction they want from you. Which makes it difficult for them to control you. And if the narcissist cannot control you. They're going to leave you. Two. New supply. Once the narcissist has used you up. They will begin to devalue you. They will begin to seek out a new source of supply. They need to have this new person available. Before they're able to leave you. Because they're looking for your replacement. They're looking for someone to replace you. But before they're able to do that. This new person needs to be under their control. They need to be a good source of supply. They may feed off your negative fuel. But once they've found a suitable replacement. There's no reason for them to deal with you anymore. So they will get rid of you. And then invest all of their time and energy. Into this new source of supply. Three. You're damaged.  They just want to hurt you. They will push to the point where you can't take anymore. And then they will pull back. They will give you a chance to recover. Just so they can do the same thing all over again. Because they don't really want to destroy you. They don't want to take it that far. Not because they care about your well-being. But because they don't want to lose the conveniences that you're providing to them. They don't want to lose their supply. And it's not good for their image. They have such a strong desire for fuel and control. Sometimes they may take it too far. They may break you down completely. Until you become completely numb. You're no longer able to provide a reaction to them. You may end up in jail or in hospital. You're no longer able to provide them with fuel. But they have no empathy for you. They feel entitled to do whatever they want. They take no accountability for their actions. So it's easy for them to move on and forget about you. All they care about is fuel and control. So they will focus their efforts on a new fuel source. Who they see as likely to succeed and provide them with what they need. But this new source may not be ready to be advanced to the primary position. Because they damaged you before they got the chance to groom this new source. Which could create another problem for the narcissist. But when the narcissist damages you and breaks you down. They have no use for you. At that point you're no longer cost effective. You cost more than your worth. And the narcissist is all about making a profit. They're all about making a gain. So if you're no longer an advantage or benefit to the narcissist. They will get rid of you. Even if they're responsible. Even if they're the cause of it. From the moment they met you. They saw you as a means to an end. Thank you for watching. I hope this video resonate with you. Please like, comment, share and subscribe. If you would like to donate. My PayPal link is in the video description. Coaching Inquiries. You can email me at coaching.narchsurvivor.co.uk Thank you for watching. And I will talk to you soon.


Environmental Studies Environmental Studies is a multidisciplinary academic field which systematically studies human interaction with the environment in the interests of solving complex problems. Environmental Studies brings together the principles of the physical sciences, commerce-slash-economics and social sciences so as to solve contemporary environmental problems. It is a broad field of study that includes the natural environment, the built environment, and the sets of relationships between them. The field encompasses study and basic principles of ecology and environmental science, as well as associated subjects such as ethics, geography, anthropology, policy, politics, urban planning, law, economics, philosophy, sociology and social justice, planning, pollution control and natural resource management. There are also many degree programs in environmental studies including the Master of Environmental Studies and the Bachelor of Environmental Studies.


do we start okay so we'll do a quick talk about why and all in Xamarin forms we compile Xamarin to IL it's actually very similar to the tour that Andrea did earlier this morning where she transpiled TypeScript into IL you see a very similar pipeline very similar concept but it's in the context of compiling Xamarin, Xamarin 5 we'll come back to that in to IL we could we but but also this concept could be used to compile any resource that is that needs to be interpreted runtime I'm doing this talk as well because that's one of the black box of Xamarin forms very few people know how this works very few people know how to contribute to this part and we're just scratching your surface but that will explain you how it works so I'm Stéphane I work in Xamarin forms since 2013 prior to that I'm using and contributing to open source since before 2000 I've been a contributor and maintainer on left spot I've been a contributor on moonlight on mono on some other open source project as well you can reach me on Twitter or on github so I'm by saying that I work on Xamarin forms since 2013 I actually I met Microsoft for the past two and a few when Xamarin was acquired by Microsoft so Xamarin forms Miguel is in there to correct me so it's fine Xamarin forms is a it's a framework to create at first mobile applications and you build your application once and then you deploy it on any of the support target and the application will be native on that application on that on that platform over here you see iOS, Android and it might still be WP7 or it could be it could be UWP I don't remember which at which time we took this this picture so those are those were the main targets for Xamarin form at this time we we support deploying Xamarin application to iOS, Android, macOS, UWP, WPF, GTK, Tizen, ui.cs so the one you saw earlier and probably still a few others so at Xamarin we maintain the backend for iOS for Android for UWP for mac all of all of the other backends WPF, Tizen, GTK are contributed by the community so Tizen if you don't know Tizen Tizen is the OS that runs in your Samsung TV or in your Samsung dishwasher so if you run-to-run application on your dishwasher it will be a Tizen one it also Tizen also supports some some wearable devices so this is Xamarin forms who is using Xamarin forms great yeah but I know I know those guys okay so in so Xamarin forms if you see this all of those controls are native to the platform so this is this is a this is an iOS map this is a Bing map and this is a Google map but but the code that runs that is exactly the same everything is native at the time of rendering and we create a UI either in C sharp in F sharp or in Xamarin what what interested us at this time is Xamarin forms also open source it hosted on GitHub so it's open source almost since I think we open source it a bit before being acquired by Microsoft so it's it's been it's been open source for the past three years we get a lot of external contributors the community is great it happens on GitHub you you'll see the GitHub address a bit later so this is a very simple example file who's not familiar with Xamarin no okay so Xamarin is just a descriptive language it's not a programming language it's just a descriptive language that can create objects and assign properties so there is no conditionals there is it's not it's not a terrain complete language it's just a decorative language and in this case we just create it it's a it's a subset of XML I mean it's XML it's XML compliance so Xamarin is just XML so it you define the content page in the content page we define a stack layout and in the stack layout we define a label with a text and that text is bound to a property of the context so that that's Xamarin when you see this basically you've seen most of what Xamarin is so it's just quite simple what we used to do on Xamarin.Forms is taking this Xamarin shipping it as an embedded resource in the assembly and at runtime when the view had to be inflated we were extracting this resource parsing it at runtime parsing it to an ST and then expanding that using reflection so it becomes a full object tree so from that we turn that to actually an object which is a content page that contains a stack layout that itself contain a label with a binding so you could write the equivalent of C sharp code for that it would take something like 15 lines the problem is if you if you if you come back to the previous slide on the middle there was an Android device and Android devices are quite diverse you have the probably the din that the guys over here having in their hands those are Samsung those are LG but but there is just a full set of devices in Android that takes something like 60% of the market that are low-end devices something that costs less than 100 bucks or that they've been bought more than three years ago and those one are single core old core very few memory and when you start doing parsing of big files on those using reflection on those creating tons of object because you need you need object and then garbage collecting them you end up with quite bad performances meaning that for large for for for a large example file turning that example file into an object tree could take a few tens of milliseconds like 60 or 70 milliseconds just to interpret the input and having an object tree which is not yet at this time rendered on screen so that that that that that's 70 minutes again that or 60 or it depends on the dependent device that that were just lost on which that that was not come not compressible time yeah so so the the main the main reason for that is the main problem for that the parsing at runtime inflation using reflection is performance on Android so as we are mobile application mobile application most of the time 99% of the time are self-contained by self-contained I mean that all of the assets are already part of the application itself yeah it can connect to external servers but most of the most of the views you would in in in another application that's not informed you would write it in a XML in in in Android you write it in Swift or Objective-C in iOS and so why so everything is known at the time of the compilation so we could technically it's not everything that we know that that we know at runtime it's also known at compilation time so why not keep the capability of writing example files because example is a great way to describe UI why not turn the keep this capability but turn that into something that it's actually compiled and as fast as if you have described your application using C sharp C++ Objective-C or whatever and be actually compiled into the assembly so we we we we we we can do that and that that's an advice that you you have to use for all of your mobile mobile application if you have a resource if you can do something at compile time instead of at runtime you have to do it if you have an image and that image need to be resized it's better to resize it on your computer time at the time of creating the application instead of resizing the application resizing the image at the time of rendering if you can if you know the size it would be rendered at resize it before because everything that's done on the device is done a million times instead of being done once on your machine and it's done on some low-end devices yeah I know that if you if you have a if you have top of if you have a top of the range iPad it's probably more performant that this laptop but that's not the case I mean it's a case for us in this room it's a case for people in the West but it's not the case for the for for the rest of the world most of the world and the target the big market for the for the mobile application right now the market for expansion the market that the people that needs applications is it it's Africa it's Asia it's and and if you if you go there you you don't you don't feed developers with the same privilege that we have over a year in Europe in the US and you they don't run they don't really run with the same constraint so so so we we need to think about the performance we need you we need to test our device or application not on our personal devices we need to test them on actual devices use on the field so what do we do so we we would we achieve that compiling XAML into IEL so we have that XAML that's exactly the same as before and we pass that to an AST an AST yeah it's just a tree it has a content page the content pages property content which is a stack layout which is a property children and the children is actually a label which has a name and a text this is actually actually the exactly the same parser as the one we we use to use at runtime is a marine form it passes to to an AST and then we on the AST we run a few we run a few visitor visitors so we implement a visitor pattern and we go or we go on all our nodes and do some stuff if you yeah for working on trees like this on the AST this important is it's something so a really good one because you can work the tree multiple time without modifying it and so we we have everything in our tree is an I node and we have some visitor that that that implemented that implement the node visitor so the most important one in this case because I told you XAML is a language for creating object and assigning properties so we have a create value visitor and we have set properties visitor so that that's what we do so we we at first create all the objects create a content page create a stack layout create the label create the object that will be set create the binding and then on a second pass what we do is setting the name of the label to label setting the text to a binding setting the content the children of the stack layout to the label and setting the content of the content page to the stack layout and we do that using monosysil monosysil is some now some library that generates and generates and inspect assemblies so it's used for example at Xamarin we use it for the linker the linker is the tool that you run on the fully build application and that will remove all the stuff that you don't need and again if an application is fully fully fully contained you can follow every pass and you can find that this function this class this type this property is never used except if it's used by reflection in that case we don't know you have to markup but we can remove everything and we can we can reduce the size of of an assembly that you might think that you do not write code that's not used but when you when you write code you depend on MS core lib if you write a seizure application and you don't use every single function of that MS core lib so you don't have to ship it so Cecil does that Cecil has been around since 2004 and it's done by by our friend GB GB yeah a few years ago he was living in France so he was he was coming to Fosdam every year but no time removed to Seattle so do we do it so I told you that we just right we are generating I L this is the I L we generate for the example the example I've just shown you so this is the this is the I L this is the equivalent decompile C sharp if you know C sharp so we create the binding extension the binding extension is the markup extension with the curly braces binding we create the label we create the stack layout and that's and we store every single of them in a variable binding layout stack layout we do that what time is it okay and then we set the properties exactly with the I L we so this is the code we generate from our example to I L compiler so and this is quite equivalent to this C sharp so we set the text as the past property of the binding we set we set the the text to the past property of the binding it's over there we set the binding to the label the label is the variable one which is over here we add the label as a children of the stack layout and we then set the value content to the stack layout and then we return if you look at the number which we are quite high because there are some other vitro that generate stuff those are for the ability of names for the ability of namescoping so you can do fine name many maintaining stair state and so on so it's it's a bit more complicated that just it but this is this is the this is the gist of it this it's it's it's the minimum requirement and then yeah we we need to support some more complex when you have references between parts and that that's why that's why it gets harder on performances it compiles XAML faster than the equivalent C sharp so XAML is slightly less verbose than C sharp so if you have to write the same code in C sharp that you would write in XAML you would have three to five time more C sharp code because all the binding is done automatically you we we most of the time create the object and assign the properties on the same line something that's not done usually in C sharp so this is this is a run that just that I just did this morning so my laptop was on the poor reserve so it's was on so those number are the order of magnitude is right the number are not are not describing the the reality but basically the XAML C for 1200 line of XAML took three times less than this number of C sharp and if you multiply that by three or five you you end up seeing that we are a bit faster than Roslyn we are on the same order of magnitude as the the old monocompiler I think I've missed something okay so the runtime performance is totally worth it we are inflating the view really fast most of the time we inflate the view so we turn the XAML not the XAML because XAML isn't ship anymore but we just construct the object in a few milliseconds we also I I haven't show you that nor explain but if you take this this is a markup extension it actually can get compiled just like all of the markup extension and we but by doing a compiled binding if you know what a binding is it's a way to link between your view and your view model and most of the time we do that by reflection and by connecting the arrow reflection to identify property change but if you that if you if you know the type of the view model at compile time you can actually create a function that does that and cut the cut the the reflection from it and so we have a boost up to 200 times on binding so bindings are known to be not that fast and that's the case in most languages because they are they are syntactic sure they are convenient for the for the developer but they are not known to be fast but if you manage to keep the syntax of the binding and turn that into actual actual code at compilation you get the same performance that if you were observing the object yourself so if you want to know more or contribute to example in form it's on github it's over in slash cuz I'm in form and that's it do you have any questions no depending on device but if you know do it if you don't it's probably but I made you what was just an example you can you could compile if you have huge json file that you ship just your application you can't think of a way to pre-process them because those are stuff that are expensive to process at runtime and I made was what was one was one of the was one of the example but yeah most of the time you don't know the exact resolution but you know if you have telemetry on your application you probably know what are the 10 most known size at least for icons and some of the image not the image I take full screens but most of the time those those one you don't ship them with the application an image I take full screen except if it's if it's a background you don't ship it it's downloaded from from a web service installed in it's stored in your local storage for your application because you're doing a photo application you're doing a news application and for those one there is very little we can do but most of the time that's a single image on a page but if you have a UI that you fully drawn with images because you have a button you have a pen you have and if you if you don't pre-process those image you will pay the price and if it matters if if the the the customer experience matters to you and it should so you should really measure what takes time in application and see where you can that's free time that's really free what a question in the case of the sample you we have some blog about it but to be able to compile the bindings we have to yeah we are the Q&A thank you to to for the example competitor to be able to compile bindings you have in your example to tell this is the expected type for the view model and so we know that it was way out of this 30-minute introduction to compile example so but we have some blog from David about it so you just tag it at the high level and you tag it at the least view level so you know that for your data template it will be this and we can compile everything so we are we are still this this is actually shipped for the past to another fewer it's been enabled by default for the past year and a bit but we're still working on it we still doing more and more computation and less and less at runtime just to save time question yeah for example I don't know I would say just measure measure everything oh yeah I have some money back to you but where's our next speaker great yeah missing speaker okay that is his footwork hi are you Michaela I am hi Michaela I'm Steve nice to meet you it's fixed do we have a level somewhere that we can see if it's good or not okay well hopefully it's okay okay okay I'm trying not to touch anything okay got it all right let's get okay hopefully it'll be get off my iPhone as well oh busy okay oh