 So, can we just, I mean, just read this if you haven't come across it before. I guess there are many people still to come, or I don't know, we'll just wait for a minute, let's say. So, I guess we'll start. So, all of us have biases. It's very difficult to see them. So, biases are not bad as such, but most of the times, I mean, they are powerful enough that we don't, and invisible enough that we don't realize they are with us. So, this talk is about, I mean, I want to nudge us, not just you or me. I mean, I am also basically a journeyman in this. This talk is about nudging towards explorations, and we have heard probably a lot of frameworks and all that. There are things that can be done in JavaScript that's not just about frameworks. So, we'll be, I mean, seeing a few examples, and I will try to give my thoughts about how to think about these things. So, the other thing that is a sideline to this is that biases limit our explorations, and that's the important part that I would like you to consider when you, I mean, what you take out of this talk. So, I think of explorations as partly building models. Building models is like, I mean, you try to understand what a framework does. You try to understand what a data structure is, what the tools are, how they are built, what the internals are for the frameworks and so on and so on. Seeing possibilities is about connecting these things. So, you understand a data structure, and you understand a tool, and you see the possibilities coming together. That's basically seeing possibilities. Again, I will talk about the biases that come when you're trying to do these things. Diving in is just, once you have the idea, you just get into doing it. So, all of these are affected by our biases. I mean, how much we explore, how much we build models, what possibilities we see. If we always think about frameworks, we are always going to think about possibilities with the frameworks. So, yeah, demo time. So, I've connected my phone over there, phone screen, and this is a Chrome browser running on my laptop. Google open on my laptop. I'm typing this on my laptop, and the phone is showing the side effects. Okay, you see that? Okay, so now I'm going to switch over to my phone to try a demo. Do you see what's happening? How many of you have an idea of what is going on? Yes, the browsers are synced, yes, but what about the DevTool? I mean, so did you see what I just did? So, on the mobile, I'm changing the DevTools, I mean, changing from the DevTools the color, and it's going, I mean, the updates are happening over here. So, on a local desktop, what will you do? I mean, if you have a site to debug, you will open it, open the DevTools, change it, and see the changes. Okay, this is like the website is open over here, and I can see what's happening on the website, and I can change the, I mean, I'm basically, so let me, it's a little risky to do, but I'll try. So, basically, I mean, this DevTools is attached to this browser session, and it's happening over the internet. You can't figure out where it's coming from, but essentially it's coming from the browser. Okay, so did any of you find this interesting? Just curious. Okay, okay. So, what's happening? So, I'll, I mean, you guys think about what's happening, but I'll share the story of how I did it. 2012 sometime, September, there was this article on HTML5 rocks about sharing, I mean, it was about screen shares, but there was this GitHub, I mean, there was this mutation summary thing, which essentially mimicked all the DOM changes from one tab to another. So, it's like any changes happening on a DOM, it will basically collect it and you can do whatever with it. I mean, you can send it or whatever. So, the whole idea was about whether these DOM mutations could be sent over the internet. Okay. So, I mean, I'm getting all the changes that are happening on a browser tab and I want to send them over the internet to some place else so that somebody else can look at it. Now, if we are doing that, why not add a debugger session to it? Okay, to the same browser. So, I mean, to do that, you have to figure out how to tunnel your local system to the internet. Have you guys heard of local tunnel and GROC? Yeah, so go tunnel is essentially that it's just that this allows an API so I can basically program it to do things again, to create tunnels and send out. So, what's happening is DevTools itself can be run as a server on any browser. Okay, so if you start the browser with a parameter, the DevTools will be running as a server so you can go to a specific port and you will see the DevTools are rendered over there, attached to a session. Okay. So, this guy basically makes it accessible over the internet. Okay, that's why I had to write good. This is not in JavaScript. This is in Goulang. But that's a separate thing. After that, I had to basically integrate it with something. I mean, this is again something I wrote which would package all of this. So at the user side, I mean, basically this browser that was there on the left side, it had to be opened with the extension. So let me share. So this extension basically is what's doing the mirroring of the webpage. So, I had to do things so that the browser would install the extension and create these tunnels and basically allow the mirroring of the whole DOM from one, I mean, over the internet. So, yeah, I mean, this took me around three months to do. The biggest part was figuring out Gotal. And now it could be done much better. I mean, the web thing, I mean, even WebRTC has something called WebMirror or mutation summary, something which allows much better mimicking. Now, the whole point is, I mean, see, I could have given up if I had thought about tunneling and it's not solved. And I mean, you can figure out these details. It's all open source and all that, or you can talk to me. That's not what I'm trying to talk about here. What I'm trying to talk about is any problem is, I mean, that's worthwhile is going to be hard enough. So you should, I mean, I would say we should probably try hard enough to think about those problems rather than saying, okay, somebody else's problem. I can't solve it. I don't have the capability of solving it. That's where the diving in comes in. I mean, this is the kind of thing that affects, at least a few of my colleagues, for example, there's a hesitancy of getting into things, figuring out what's going on. So if there is some problem with, let's say, Angular, you have to get in, figure out what the source code is, where the problem is, and all that. And that's the point. I mean, this, you shouldn't be hesitant about getting into the levels to figure out what's going on or figure out your own, I mean, solve your own problems. Now we'll think about possibilities. 2011, I mean, I was, I had this habit late back then to go to the Yahoo Hack days. So I spent about a week thinking about possibilities. Now, the thing is that the possibilities that I didn't consider, I mean, it didn't take forward. I don't remember, but a week of thinking that means that I thought about enough possibilities. That's again, I mean, it depends on people to be person to person. I mean, some people, for example, pick up research papers and think about it and do it in some language they want or whatever. So possibilities, I mean, you have to basically figure out what works for you, but it's again a thing that you have to think about explicitly. So the hack that I did was to sync edits from Chrome DevTools to file system and refresh on change. I mean, so you could save something from the Chrome DevTools. It will save on the file system and it will refresh the page. Okay. So it's like you're editing the website on the Chrome itself. Again, a week of diving into Chrome DevTools source code. I mean, to do this, I had to patch Chrome DevTools to get some features that I needed. So this is irrelevant, but still the point is again, that I mean, again, I'm bringing these same things that you have to basically first think about things that are around you explore the possibilities. And then just dive in. I mean, even if you don't know how difficult it is, it's okay. It doesn't really matter much. I mean, even if you fail, you will learn something and yeah, pushing our limits. That's the two about the failures. 2010, one year before this, again, I was in Yahoo Hackday. I had a bad idea, bad execution and presentation. I was basically standing there. I didn't know what to talk about. It was a really big disaster for me. And the successful one, I did one year after that. So I mean, I'm giving you examples of failing and then doing explorations again. It's all about, I mean, it doesn't really matter how much time, how many times you fail. It's about how much you explore. That's what you learn. So yeah, failure is part of game. So this is again a possibility that we, how many of you heard about HTTP police? I guess a few of you. Yeah. So it was released recently about a month back. It's a HTTP linter. So what it will do is HTTP headers. It will figure out whether the headers are correct. So for example, if you have a caching header, it will figure out whether you have, let's say, public and private boats together. It will say, tell you that you can't have both of them together. It's a linter for HTTP headers. It's a Python, I mean, a man in the middle kind of approach. What we did, one of us basically, Rohit, he wrapped it around the DevTools thing. I mean, basically DevTools extension. So now, so yeah, here, basically it's on, I'm running it on GitHub only. And here it's showing the errors that are happening on the GitHub errors. So all the hard work is done by somebody else. Basically they wrote the, Vasily wrote the HTTP police, but there was still a connection to be made. So for our environment as DevTools, there was still a connection to be made to connect it with the DevTools. And that's what, I'm not sure if anybody else is working over here on the same problem. Yeah. So again, I mean, you have to explicitly think about these things. I mean, if you wait for things to happen to you, it's, yeah. So the other thing, or the first thing that basically spans both of these concerns, the possibilities and the diving in is building models. And building models is about how does things, I mean, how do these things work? How does browser work? How does encoding or decoding work? How are frameworks implemented? Intuitions behind stacks, recursions, maths. So, I mean, the reason why it's important to have models, build models is because they help us explore. I mean, even if you have a wrong model, you can still use it to do, I mean, or to figure out that it's wrong. It still allows you to do things. If you don't have any models, you're just going to use whatever you know. And that's why it's important to explore the things that are the frameworks, the internals of them. And yeah, so this is another project that we, one of my colleagues did. So if you go to Amazon search and apply some filters or Flipkart or any of these sites and apply some filters, this is what you get on the URL. It's basically a state of the current selection. We built an application for a client and this is basically the UI for the application. These are the options that you could choose. And all of this was to be saved on the front end in the sense that you don't want to save this state in the server. So you want all this to be saved on a URL and the user could copy paste and it should again come back to the copy paste and send it to somebody else. It should come back again to the same state. Yeah, so that's where this project came in, encoding and decoding. So let's say this is the state that you want to encode. Okay. And I mean, let's say this is what you want to put in or put it on the URL. This is another state. Let's say, okay, if you look at the differences, there are only basically these things that vary across the different states. So the basically, I mean one of them, for example, the religion would be from one of these lists. So we could save it basically by saying, okay, this is zero index or one index or two index in the this thing. So this is achieved by, I mean, it's not really a it's similar to what every one protocol buffer, etc. do, but it's different. That's again, I mean, something we can talk about later. Again, the point is, I mean, you have to, again, the models that he had built about encoding and decoding helped him solve this problem. Okay. That's what is important that you need to create models about things, algorithms or data structures or frameworks so that you can use them in the problems that you see. So this is something that I had done for slideshow. So this is a slideshow uploads the uploads. You have to basically do it on this three show progress show network failures errors and all that check for bands Q files for conversion. All of this is happening while the, I mean, things are happening in parallel while the upload is happening. All of this is part of upload. Now, again, I mean, I could implement this in a straightforward Java, not straightforward, but JavaScript way of calling functions and all that, but there is a better approach, which is state machines. And you could implement them in, let's say, 50 lines of code or something. And it allows you to basically abstract this complexity in a better way. Again, I mean, knowing your models and understanding models of stacks or state machines or. So how many of you have done testing? Moka or Jasmine or. Okay. How many of you have tried to implement something like that? One, you have tried. Okay, how, how, I mean, did you share the results or did you keep it somewhere? Did you keep it on GitHub or something? No, how big was the code? Okay. So this is what basically, I mean, I guess everybody knows about this. This is the complete sync, not the sync version. A sync version is a few more lines of code, which we give as a recruitment problem, but that's a different thing. This is the whole, I mean, this will implement the whole API. So once you understand this, I mean, you could probably explore about how to write. The point is not what's happening in there. You can figure out, I mean, it's open source and I can share when we talk later. The point is, I mean, we can explore and understand our tools better. We can explore to find connections between our ideas. The only thing that's stopping us is the hesitation that somewhere there's a limit that we shouldn't cross. And yeah, that's basically the end of my talk. Yeah, so now you can ask questions. No questions. Hi, pure. Okay. The remote DevTools thing that you showed was really interesting. What I wanted to ask is that is it possible, will it be possible to do things like get profiler information, for example? So the DevTools has a lot of other things that is network. It's a complete DevTools that comes with the Chrome. So you can actually do things like how the Chrome's memory is performing or the timelines and all that. Yes, yes. It's a complete thing. Yes. Okay. But the catch is that you have to run Chrome via a command. I mean, it's still the Chrome that user has, but you have to run it via command line thing. So when I run this, basically it gives me a domain where I can access the whole thing. This has to be run at the client's client side. So there's a binary that you have to download. The client has to download. So does it patch Chrome itself or? No, it doesn't patch Chrome, but it starts Chrome with certain parameters. It installs an extension. It creates a separate profile. Okay. Okay. Thanks. Yeah. Quite interesting talk. That's a lot. My question is how do you approach learning? How do you approach learning? Let's say if you pick a problem that involves you learning a new tool, let's say systems programming, which you have no idea about it. How do you approach it? I mean, you just have to, that's probably the biggest thing I would like to tell everybody that if you don't know something, it's okay. I mean, it's like wrong models are okay. I don't know math. I have three, four years I have been trying to understand. I mean, I have some models about math, but I know they are wrong. Okay. It's just you bang, bang your head to the wall till it breaks. So that's the, I mean, if you want to understand something, machine learning or whatever and all that, you just spend that effort. I mean, the people who do good in that, they have spent years. Okay. So that's the, I mean, you have to build the models. That's what the point is. And the building the models, the hesitation is that, I mean, I, this boundary is something I should not cross. And that's, you shouldn't have that essentially. No more questions. Thanks. Thanks for listening.