Good morning. Thanks for coming to this talk. So my name is Dev Naatsana and I wanted to talk to you about Famous today. It's a new JavaScript framework that's come out and we are using it at CosideIO and we want to just talk about it to you all. So a little bit about myself. After graduating, I basically worked in the valley for about five years, first at Cisco and then at Salesforce. So at Cisco I was doing very low level device drivers but then at Salesforce I was on the analytics team and while I was on the analytics team, we were building a phone gap based mobile application. So I had some experience with developing hybrid apps, right? But then in the beginning of the year, we finally decided to take the plunge and I started Coside.io. So Coside.io is basically, it makes your enterprise sales team more efficient and we sit on top of email and we look for certain text markers to decide where in each pipeline, where in the pipeline each deal is and move things along. So this is like a big pain point in the customer relationship management industry. So the thesis of the talk today, that I want to say, the JavaScript is ready for primetime mobile app development, right? And this is more like, so when I went to graduate school, one of my professors, the course was stochastic processes. One of the hardest courses, he said, my job is not to teach you the answer, it's to teach you to ask the right questions so that you can go and find the answers for yourself. And I think I want to take the stock in a similar light. The idea is to take you through our thinking process when we were evaluating this framework so that you all can use the same questions or alert us about other questions that we may not have thought of. And the answers will actually be different for everybody. There's various, various use cases, various trade-offs to be made, and really, that's what engineering is all about, right? So the question is, why do you care? Why do you care where the JavaScript actually becomes a thing for mobile app development, right? And first of all, because this is a JavaScript audience, right? And some of you want to use your skills to build mobile apps. But there's another reason, and that's because in the beginning, all your model used to reside on your server. But ever since the phones came out, your clients are actually connected to your server using a very lossy, low bandwidth network, network pipe. And one of the things, this, one of the architectural decisions that this forces is that you have to now take a model and push it more and more of it onto the client, especially if you want a very responsive app. Now the device fragmentation kicks in, and since you have different platforms, you actually have the model in, like, you have different code bases for the model. And if the code bases, like, fall out of sync, there are various problems that can happen. So let's take an example of a simple bug. So in Cosa's case, we have, say, an analytics engine, right?  Say I want to say, in the SMB segment versus enterprise segment, how does my pipeline look like? You want all that to happen on the client without having to take a server round trip every time. So say you have your iOS code base and your Android code base, and the filter function has a small little bug in it, because there were different teams that were developing this. And it's a very simple bug. It's like either if less than or if less than equal to. And the problem is that if you look at this table, you actually end up seeing a different value. And this is really bad for you, because in one meeting room, you now have a guy on an iOS device and a guy on an Android device who can't concur on the same number, and they lose trust. And there's nothing that's worse than losing customer trust. So if you do buy into the idea that you want a unified code base for the model, what choices of frameworks and language do you have? The first is C and C++. And you can actually, like on iOS, it's very native. But on Android, you have this concept of a NDK. And then in JavaScript, you actually have this framework called M-scripten, which Mozilla is coming out with, which takes a C++ code and converts it to JavaScript code. And this is actually being used by some video game developers because a lot of the legacy game engines tend to be on C++. So it is like, there are people who are using this. But the other piece of it is JavaScript, your other. Your other option is actually JavaScript, right? And that is using some, a wrapper, sort of like phone gap for Android versus Android and iOS device, and rendering it natively on your web browser. So one of the structure of the stock is basically to talk about the features we thought were important in building a high quality app, right? And we'll go through them one by one. So first, let's talk about performance. So the first thing you hear when you talk about hybrid apps is that, oh, JavaScript is slow compared to native, right? But we're engineers here. So let's try to dig in a little deeper into which piece of the stack is actually a bottleneck. So if you look at the stack, on the first, like on the bottom most layer, you have the device OS, above which you have a wrapper, sort of like phone gap. Then you have the JavaScript interpreter. Then the browser rendering engine. And depending on your mental model, you can think one above the other or below. But for this, the thesis is that they're different layers. And above all of that sits your app. So let's talk about the wrapper. So the wrapper, the point is that you want the latest browser rendering engine for a very performant application. And unfortunately, things like phone gap, default to the default browser. The problem with this is that the default browser before Android 4.4 was not Chrome. It was actually the Android browser, which would be fine in an iOS world because iOS users tend to upgrade to the latest iOS that comes out fairly quickly. But on Android, if you look at the Android adoption usage and we pull this right from the Android developers page, most of the world is still not on KitKat. And this means that you actually have to address the issue. So if you want to use more powerful features like WebWorkers or, say, WebGL, you actually need the latest rendering engine. And there are people who are trying to address this. PhoneGap also has an option for downloading the latest. But the problem with this is it increases your app size. And that is the trade-off that you have to decide whether you make it or not. It may not work well for the bottom, like the low-end smartphones, but for the high-end smartphones, it's a different issue. So then let's move on one layer of the stack to talk about the JavaScript interpreter. And the point is, if you look at the history of interpreters, it used to be true that back in the 80s, it was performant to write assembly language code and you could actually get very good performance out of it. But today, not many people write assembly language code. A C compiler has become good enough. And so the question, the thing you want to keep your eye on is when is this compiler becoming better? So if you look at a JavaScript, the interpreter used to be slow. And then Google invested in it. And they came out with VA. They spent a lot of resources building it. And now it sits inside Node.js, which many of you all actually use on the back end. So if you look at JavaScript performance, when it comes to native Compile C, it's about 80% when it comes to matrix multiplication, at least. And I'll get into a little more detail about why matrix multiplication is important, but it has to do with computer graphics. Then let's talk about the browser rendering engine. The question is, is the browser rendering engine really inefficient? And in some sense, this is true, because browser rendering engines were built to render documents, not the kind of rich apps that we are building today. And so let's talk about an inefficiency in the browser rendering engine, and that is layout thrashing. So there's two codes, one on the left, one on the right. And both of them have the same functionality. Yet the code on the left causes two paint cycles on your browser, and the code on the right causes one paint cycle on your browser. That means the code on the left takes two, like its FPS will actually be lower than the code on the right. And so it will give you a jerkier UI. The problem is, when you're building an application, it's very hard for you to keep track of this exactly how the DOM is rendering, how many paint cycles are being caused. And so now you see new libraries with things like Shadow DOM which are trying to address these issues. But if you actually come from the multi-threaded world, you will notice that actually there's concepts like serializability and compilers like GCC and JVM are actually allowed to reorder your statements so that they maintain the same, as long as they maintain the same functionality so that they can use things like, if a variable is already in cache, then let me use that while it is still in cache. And the reason I want to call this out is because, again, the analogy that the JavaScript is finally, that entire stack is fundamentally a compiler and when people talk about performance bottlenecks, it's not the language that's the performance bottleneck, it's the compiler and the interpreter. And that is getting better. So what you have to do is actually keep an eye out for what new technology is coming out, what impact performance, and when it becomes good enough for your application. So to create, if you take the notion that right now the apps that we are creating are basically three-dimensional worlds with lots of animations which have been rendered onto the two-dimensional screen of your phone, let's go to another industry that has actually done this for the last two decades, and that's the video game industry because maybe they have some things to teach us. And the fundamental premise of computer graphics and the video game industry is that all the entire 3D world can be brought, projected onto a 2D screen using a bunch of 4x4 transformation matrices. You combine them in various ways to get the positioning that you want. Anything like rotation, skew, or even translation, or if you want to resize one compared to the other to bring things up front on the z-axis, it can all be expressed with the series of these multiplication transformation matrices. And that is exactly the trick that Famous uses. What Famous does is it takes your code and creates its own render tree. So rather than relying on the browser's inefficient render tree, it actually takes your own render tree. It creates its own render tree. And then if you look at how animation works in the browser, every paint cycle that you can register a callback function that gets called whenever the browser does the next paint cycle, which is about every 16 milliseconds for a 60 frames per second, which is considered the benchmark for good UI. And what it does is it does the render tree and it renders the render tree. When you do this fairly frequently, say every 16 milliseconds, it gives you the notion of unobstructed motion. And that's how animations are created. So let's take a simple example of an app that's built, derived off of our app. And it's basically, it has a scroll view. And this is your, whenever you're taking actions on the customer relationship management side, whenever you're updating a deal view, it gives you an activity feed. And on the other hand, we have the home screen where you basically have course as logo rotating. And this was more to show you how the physics works. So let's actually look into this app and see how exactly you structure it. So the first is you need to plan out your render tree itself, right? And so you have a header view, a content view, and a footer view. And the way it works in famous is you have views. So if you've looked at UI development, you basically have views and the views as sub views and ultimately you have like basically rendering elements, right? And it's sort of similar even with this framework. And what you use to move views around is called modifiers. So let's look at the header view. And the header view is basically, it's a surface, right? And the surface is famous for, speak for a div element. And what it does is you use the modifier to position the div element. And if you look at the div that's generated, you basically, if you notice very carefully, you have a Matrix3D WebKit transform. And Matrix3D is basically a W3C API that tells how you're going to use this 4x4 matrix that we spoke about to position it correctly, right? And this, because this is the reason it's important that it's a W3C standard, is because now you can expect every single browser to support it going forward. And so what you see over here is you basically had an almost identity matrix because this was at origin and you actually didn't need to move it anywhere. But now let's go into the footer view. Footer view comprises of two sub-views, the home view, the home tab view, and the activity tab view. And the only difference between the header view and this, first of all, it's, you're using an image. So it's an icon. And just the same way a surface corresponded to a div, an image surface corresponds to an image tag. But the only difference between this and the header view is that you actually want to translate it to the bottom of the screen. And so as you see, what we've done is we've added a modifier and it translates it 430 pixels. This works for iPhone 4. But the point is this would be a variable that's proportional to your screen size. And as you can see the 3D transform matrix, it actually moves it by 430 pixels. Now let's go into more complicated animations. Let's talk about how you do the spinning logo. So if you look at the spinning logo, now instead of translating it to the bottom of the screen, you actually want to rotate it. But the only thing is you want to rotate it as a function of time. And that's exactly what we're doing. So you actually take date dot now, and that gives you the most current time. And it keeps incrementing every time the request animation frame is called. So every time a paint cycle is generated. And what you do is you rotate it a little bit more every time the paint cycle is generated. And so long as you do it at 60 frames per second, it looks like the whole logo is rotating. And if you look at the DOM itself, right, if you look at the div that's actually the HTML element that's actually generated, it's looking like a whole bunch of numbers because it's basically sine theta and cos theta based on whatever your theta being date dot now minus initial time. And so what you see over here is that you've got a fairly complex animation based on something that is actually easy to reason about, not just for you, but for the guy who comes in and reads the code later. Because in any reasonable application size, a code is going to be read at least four to eight times for every time it is written. And that's just something you should design for. Now let's talk about tab transitions. So for tab transitions, you basically saw that every time we click on one, a one view is brought to the front and the other time it's replaced with a different view. So how do you address that issue? And so basically if you look at the code, it says that if I click on the home tab view, then show home tab and hide the activity tab. If I click on the activity tab view, let's show the activity tab and hide the home tab. So let's refactor this code a little bit and have a variable called state. And I just make state zero or one. And then say my display function of the view is proportional to either state or one minus state. So what this does is establishes a constraint that only one of these codes will be, one of the views will be visible at any given point of time. And how do we bring the view forward or backward? We basically change the opacity. So this is like sort of a CSS property, but we change the opacity from zero to one based on which one is clicked.  The reason you bring it up on the Z axis is because you want to capture the events on it. So if you're scrolling, you want to capture the click. You want to capture various events on it. Again, this is something that is fairly easy to reason about, not just for you, but the guy who comes in and reads the code later. So, but then what you see over here in the previous state is the state was either zero or one. So at T zero, you basically have the state as zero. And then the next time it's clicked, it goes to state one, and the next pain cycle, it automatically becomes the new view. The problem with that is it's very jerky. And jerky animations are not very good. So you want to make a smooth animation over it. So how do you make a smooth animation? And the construct that famous gives over here is actually called transitionables, right? Another thing I wanted to point out is this was basically a tap transition, but you can generically use this to synchronize various UI elements inside your screen.  That is also a similar constraint to this. It's just a synchronization primitive across your UI. So now let's talk about transitionables. What does it do? It basically takes a number and says that from start value to end value, instead of making it discrete, I'm going to make it a smooth transition depending on a curve that you specify. So you can specify any kind of a physics simulation, see a spring action or something like that, or you could specify some kind of a tween curve, right? And so if you look at the example below, you basically start out the state as zero, and then you tell it, transfer it to state one, but do it over 100 milliseconds and use a curve called ease in these out. The curve itself doesn't matter, you could think of it as a spring animation, but the point is now you're doing it over 100 milliseconds, 100, 300, whatever, it's much more soothing to the eye. And so now you see that you basically, using famous, you've been able to construct very complex animations and yet reason about it in a very simple manner. And I think for us, we think this is like really, really powerful, right? And this is why we like this framework. So what about the other features? So we've spoken about performance and how famous impacts the layout engine and it goes a long way forward in solving the performance bottleneck, right? What about the other issues? What about the other pieces to a really complex app? And the first is modularity. So back when you were in college, you probably wrote programs that were about a couple of thousand lines and a lot of your classes were in the same file. And yet after your first job, what you would have seen is that they had strict code guidelines, like, okay, one class per file and not more than that. The reason for this is because, again, because your code is going to be read much more often than it's written, you want some kind of a structure around it for the guy who hasn't coded it for the first time. It's no different in JavaScript and this problem has been solved in JavaScript using AMD frameworks.  So it might give you the impression that you need RequireJS to run famous. That's not true, but it's just very good hygiene and so I think they've just included that inside by default. The other thing you need to build a really large scale app is some kind of a structure, right? So on the server side, you usually use design patterns like MVC, to basically create some kind of a structure so the code gets less complex and again, it's no different in JavaScript. So we use Backbone.js, it's not the only MVC framework, but we use Backbone.js. The question is, and this allows us to keep track, decouple the view code from the model code very standard MVC tradeoff and the only question is how do this play with famous, right? So if you see controller logic, there's no point writing a framework for your controller logic because it tends to be very application-specific. So we use Backbone.js, we use it only for the model. So then the question is, how do you combine Backbone.js with famous? And here's an example of a Backbone.js model. It's a very standard Backbone.js model that's built from the to-do app. Now if you look at Backbone.js, they actually have predefined views, events, right? So whenever a model changes, you can subscribe to either the change event or the change and attribute event and then re-render your view based on that. It's no different for famous, only you replace the Backbone views with your famous views, right? And so you basically pass in the model into your view as an argument and then every time your model changes, you re-render your famous view and that's where you basically combine Backbone.js with famous, there really isn't that much it fits in very well together. But Backbone.js is not like, I was going to slide with some people and they say, oh, is Backbone.js a requirement? It's not a requirement. There are people who are trying to build famous integrations with AngularJS, there are people who are trying it with ReactJS, although ReactJS is not a model framework, it's more of a view framework. And to mention some other integrations, you have it like the famous is trying to work with PhoneGap, with Crosswalk, Intel, that's basically. And these are the other integrations, right? Then the next thing we think we need is responsiveness. When I say responsiveness, it's an overloaded term. I don't mean media query responsiveness. What I mean is since we are building an analytics engine, you need to make sure that when you are filtering any data set, when you are slicing and dicing any data set, you don't want it to happen in your UI thread because then it feels like it's not performing. And then people complain about the quality of your app. The JavaScript construct for this is actually web workers. And if you look at web workers, the same wrapper comment that I made earlier, the wrapper argument, it applies over here. So it wasn't true in default Android browser. And so if you need to use web workers on Android, you actually need a more performant browser, a more performant rendering engine. And there are these various options that I mentioned earlier. Same thing for WebGL. We aren't really looking at WebGL right now, but if you wanted really good physics on it, you'd basically right now iOS 8 has actually opened up WebGL since some sense they've been dragged into the rendering. So if you wanted to use it, that's another reason, like another place where you'd actually need a better rendering engine. The next thing is offline access. So why do you need offline access? And that's because you're actually sending a lot of data over to the client side. And if you do it every time the user requests for, say, the latest sales data, if you don't send the diff and you send the whole thing over, it's less responsive and you're really chewing up battery life. And that just makes for a really bad experience for you. Now offline access is not a given, and this is something I've seen, especially with JavaScript developers who are coming from the Web world where you had a broadband connection between the client and the server. It comes as an afterthought, and it really needs to be engineered right from the start. This is a really cool... So I was searching for how do you simulate offline access, and I found this really cool picture. One of the advantages of this device is less than the wavelength of your 3G spectrum, you can simulate offline access. But more often than not, when you're developing, you need something on the emulator, and there's this tool at least on the Mac called Network Link Conditioner, and it allows you to simulate a network access as various kinds. Either it's a lossy network access, or it's not lossy, but it's low bandwidth various kinds. So we use something like that. And the last thing is debugging. And like latency, you want to talk about debugging on the 99th percentile, which is you don't want to say, can I debug the Hello World application that actually they show on the on the frameworks web page, but can I, if the hardest debugging problems I've ever encountered are like, only some customers are seeing this, and only some percentage at the time, and maybe they have a particular screen resolution. So you want to be able to say, can I debug things like that? On HTML5, right? Any HTML5 app, you generally tend to do most of your debugging on Chrome DevTools, right? And you basically set an emulation mode. And this has worked in the past because both Chrome and Safari use the WebKit rendering engine. But Google recently forked off WebKit into their own Blink engine. Needless to say, they did it because they thought the code bases would diverge. So the same assumption you held, saying that I can develop it on Chrome, on the WebKit engine on Chrome, and it will work similarly in Safari. Granted, there are some if conditions for mobile thing, but if the same condition doesn't hold true anymore. And this is another place where we see famous having an advantage. Because you're using the same rendering engine on both browsers, the chance that you'll see a problem, a bug in one of the frameworks and not in the other, is actually reduced. But it still remains scope for improvement. If you look at why LinkedIn moved off from HTML5 to native, they basically said a lack of tools, as cited a lack of tools as an example. And so I hope we've made the argument that JavaScript actually is ready for mobile app development but for the first billion users. As we know, like Android 1 and Firefox OS, there's a whole range of low-end smartphones that are about to hit the market or have already hit the market. And the question remains, what about these low-end devices? Will the same thing work? Will JavaScript be a useful platform on them? A point of note is that the cheapest low-end smartphone today, it's built by an Indian company called Intex. It actually runs Firefox OS. It's about 2,000 rupees. And so Firefox is definitely trying in this area, but there's a lot of questions that need to be answered. The first and foremost is does this actually have a GPU? Because if it doesn't have a GPU, it wouldn't matter if you're developing a JavaScript or native. You cannot have the same graphics, because if you take the same graphics that the GPU renders and render it on the CPU, not only will it be bad UI, not only will the UI be jerky, but you'll also drain battery life a lot. So, irrespective of whether you're hybrid or native, you're actually going to have to redesign the app if they don't have a GPU. And then the other thing you have to keep an eye out for is what kind of browser capabilities are you going to need, right? And this is very application-specific, so again, coming back to the point, here are some of the questions you should ask, and the answers will, of course, depend on you. Yeah. So, FIMS is currently being used by like a few companies. It's still in the very early stages, so like I like saying, it's sort of where Docker was like two years ago. They've raised about 25 million dollars in funding and they've got a bunch of people they're working with some big companies sort of like Intel and Adobe and all of these people, but the ecosystem is still in the very early stage, which is again something you have to consider when you're deciding to bet your company on this or not. And so, to summarize, I basically want to prove like, I basically want to make the argument that you actually have a JavaScript is becoming more performant. The interpreter is getting better. There's a lot of people who are trying very hard to make this push. You'll still find, depending on your requirements, whether you know, you're the connection between you and the client is really a 2G connection or not based on whether you actually need that kind of animation or not based on whether you need the model to be the same or not. You need to make your own decisions. These are some of the questions that go into whether it's right for you or not. And that's all I had for the talk, so open for questions. Hi, my name is Raju and now, can you hear me? Hi. Hi. My name is Raju and we are working on some technology for the presentation, but I wanted to know and how does it work with scalable vector graphics? Scalable vector graphics, SVG. Oh, okay. So if you actually look at if you look at famous, so the answer is I don't actually I don't know because we haven't had to evaluate it for scalable vector graphics. The reason excuse me, can you the reason because I'm asking scalable vector graphics is you have the two-dimensional, three-dimensional control far better than desktop GUI API. For what? Scalable vector graphics, you have a two-dimensional, three-dimensional graphical interface. 2D, 3D vector graphics. So you can create far more compelling graphics. So we are planning to develop a scalable vector graphics for a desktop as well as for the cross browser including this one. So I'm wondering how it fits into the Yeah, so I don't know directly about scalable vector graphics. We haven't had to use it. But what I do know is that even if you were doing say a 2D animation of sorts on the phone, you actually use translate 3D and just keep the process at zero. The reason you do that is because it goes to GPU. And that's sort of how famous it does it. I think they have in the roadmap for both WebGL as well as Canvas element, but I'm not sure. I haven't heard the scalable vector graphics. SPG is now part of all the HTML5. Now all the browsers are supporting HTML5. And as far as I know it is pretty good now. All the companies, no, no, I don't think famous is addressing it. My point is we haven't evaluated it. So I wouldn't... Hey, what's up? Oh, right here. So first question. By the looks of it, famous could actually become a really powerful tool for data visualization too, right? Yeah. If you merge the physics engine and use it to draw really powerful looking graphs. Right, so if you look at graphs, really interactive graphs, it's just the kind of animation in some sense. When you're filtering, you want that kind of transition. So absolutely it is. Pivot tables and data frames. And in fact, that's the direction which we are also headed because if you were building an animation engine, if you were building a data visualization library, you would need because so on the broadband world you could go to the server every time but if you look at what you want to do on the mobile device is send what's called a data cube over.  I say that, okay, you are interested in a particular product and you're the VP of sales and you want to send it for all states in your region, right? And then the filtering actually happens on the client side. So it's actually a very good use case for something like that. And I had one last question. We loved the talk. We loved the slides. Could you share the slides? Yeah, absolutely. Super. Yeah, absolutely. Thank you. Thank you. Hello. Yeah, very nice presentation. You did, you know, raise some great questions about the framework. So I evaluated, you know, we evaluated the famous month back or so. Okay. And it wasn't very clear whether they actually provide you a cross-compilation environment to the native app or not, do they? Hmm. So they're actually working on that right now. It's called a famous wrapper. Okay. And so they are working on something and actually we are part of the beta testing program. Okay. So it'll be in a couple of weeks from now. They're working on something. I know they're working, trying to work with Intel on Intel crosswalk and Intel crosswalk is basically a phone gap but they render, they bring in the blink engine and I think they're trying to work with Adobe. It's definitely on their pipeline because they don't have a story if they don't have an Android story and they don't have an Android story if they do with the default browser, but I'm not a famous employee. So this is how we evaluate it. Today your app is actually just on the browser. It's not actually installable. No, it's actually, we're billing it for iOS first. iOS is compatible to a native even today? It's not compilable. It's sort of like we use phone gaps. So you basically... Oh, you guys use phone gap to wrap it. Yeah. So it would be phone gap. It wouldn't be cross compilable. Okay. So you wouldn't, maybe we should, I don't know what the definition of cross compilable... No, no, I meant, yeah, you can put it as a native app. That's what I was on. So you can use phone gap for that. Right. But it is not like you're developing Javas to sort of like M script and write. Sure. It's not like you're developing, because I'm really wary of that code. What a generated code is just gets hard to debug. Yeah, no, no, I actually shouldn't have used the word cross compilable. I meant, can you actually wrap it in a native... So you wrap it inside phone gap and what we are saying is that on iOS, people complain less about phone gap. Everybody, people complain, but people complain less. On Android, because it's a default browser, it's a real problem and there just needs to be some kind of a solution to that. But technically you can also use phone gap for Android today if you wanted to. And I think, like I was talking to Harish at free charge, he was saying phone gap also has options to get the latest browser. I think it's more of a trade-off, like it increases your app size, so you just have to decide which one. Okay. But you can. Thank you. Yeah. Hi. Here. Oh, yeah. So hi. I'm working with Nagra and we are basically developing JavaScript application on set-top boxes. Okay. So they are further more low architecture, what we assume. Right. So they are actually, they are developing on both HTML and SVG and we are relying on our framework, which we definitely want to move on something better. And for that, we actually decided to go for something like famous plus Angular, because the combination is available, but again, we come to the problem of memory requirements. Yeah. So I want some feedback, like, is it like if I go on debugging on both the frameworks, it's like a lot of times I get pain and I lose my application time over there. Right, right. So something there, if you can. So I would say that the memory usage would be proportional to the complexity of your render tree, right? So, yeah, so it would be something that you would have to, I would run a benchmark. And the reason for this is because if you look at where famous is trying to head, it's these phones, right? It's not going to be, they're trying to do this build-all for everyone, but ultimately if it makes a trade-off, phones are a more lucrative market. And it will be proportional to your render tree. So currently famous as they do about 500 to 2000 renderable elements. This is before WebGL comes out. And I would basically run a benchmark to see, because if you're right, like if it's too low, it basically falls back to the case of the low-end smartphones, right? And, like, that would be a whole different evaluation. And the other thing is, maybe WebGL transforms, like, I don't know if you guys have a GPU or not, but if it's not, then it's really not adding any benefit to you. So you can actually then take the same constructs they do, but, you know, like, perhaps you'd have to make different trade-offs. Because it's the same thing as the low-end phones. Like, if you don't have a GPU, it's not really adding that much benefit in my opinion. One related question you talked about frames per second, 60 frames per second. If the, apart from running famous, something else is going on at the background, which is heating up the CPU, does it somehow interpolate the, you know, you drop some frames and interpolate the frame transition somehow? So, right, so the way it works is it basically, so the browser basically gives you a callback for every bifidge which, a function which it calls every time the paint cycle happens, right? And what famous does it, it calls its rendering engine in that callback, right? Which is why there was a slide on responsiveness, and that's the reason. Because if you're actually doing a whole lot of work and slowing it down, there's nothing famous can do, because that's just how browser architectures work. So the way I would suggest doing a compute intensive thing is put it to a separate thread. So that's what web workers are for. So you don't want to overload your UI thread a lot with other kinds of computation. What you want to do is you want to put it into a different thread. That's also how you do native, by the way. So if you're saving a large quantity of data onto a system, you do it on a different thread, because you don't want to over tax your UI thread. And that's, you have to do the same thing. It's basically engineering. It's not a magic bullet, right? Famous is just making different trade-offs. So I would do that. Yeah, hi. Yeah. So you mentioned about famous being responsive, right? So that means Yeah, go ahead. So it means that it works for different resolutions. Yes, but I did add that I didn't mean responsive as in media query responsive. I meant more like the web view, like responsive as in the thing that he mentioned. Okay. But yes, it does work for different resolutions. And sort of, if you go back to the slide where I translated the photo view down, it was a number. It can very well be a variable, right? No, my question is actually, can it replace bootstrap framework in the sense Oh. So bootstrap, it depends on what you're saying, right? So if you mean the bootstrap JavaScript framework. So the CSS framework is more about presentation, right? Famous is more about the layout. So if you look at the slides, you actually use CSS classes, we use CSS classes to style it. If you look at the problem that comes with CSS, it's when you have to arm wrestle with CSS to get the layout exactly right. And that's the problem that famous solves for us, is the layout. And the presentation, we could use bootstrap. If you're not, we don't use it right now, but it could very well be done because what you're doing with bootstrap is sort of styling, right? And they've got it really good. In fact, the reason it's really nice is because people are used to bootstrap. So you don't have to, you know, have it. Thank you. Hello. Yeah. Hi. This is Ritesh here. I can see you have used backbone model. So I have a question related to that. So why you have chosen backbone model and why not Angular or you have created your own model? That is one question. And the second question is why you have not used backbone views and the templating which also do the same rendering kind of thing. Right. So the reason we didn't use backbone views is because we are using famous views for the layout. And that gives us a whole lot of advantage. If you look at backbone views, they're fairly light. They basically say, if you get this event from the model, then re-render this thing. And really it's about how you re-render it. So we felt it was fairly light and it wasn't, we don't want to have any complexity to it. Since we were using famous for the layout, why we use backbone model is because I'm just used to the MVC framework and it just helps me reason about it. So it helps me say for example go to the server and collect a diff and then like repopulate it. That's stuff that I would anyway have to do but it would be my code and bad code. I might as well rely on a framework for that. I was just thinking like why backbone model like is there any advantage of using backbone model in this way or something? Interesting story that I was talking about, Hari, she's a free charge and I was talking about backbone and he goes like, no, in fact backbone is really heavy. What are you talking about? And he's like, no, over the 2G connection, my app downloads in like say about 3 or 4 seconds and it's a different trade-off. So light and heavy is a very subjective term. For our application, we don't think it's very heavy. It gives us a framework, the framework that I'm used to on this side. So it helps me reason about it in a much better manner. That's why we used it. It would really, again, coming back to it, it's about asking the right questions. Depending on what the application is, it would actually, you'd have to make an idea about whether it's heavy or not. Sure. Thank you. Hi. This side. Are you? This side. Oh, hi. So what are your thoughts on JavaScript garbage collection with famous animations? We haven't hit the issue but I think they are incentivized to solve that because if they can't, if the UI becomes less responsive because they're collecting garbage collection, the whole thing won't fly. Having said that, the way they address the issue today is they limit the number of renderables, right? So they don't limit it, it's more of an advisory thing, but they say 500. And then when you benchmark against these 500 or 2000 elements, that's not that many objects. The reason I'm asking is because for the demos, it all looks very good. Right.  So, okay, that's a great point. So, another interesting story. So, back in 2012, we were trying to look at hybrid applications, right? And at Salesforce, it actually makes sense to do something like PhoneGap because we have like hundreds of thousands of, you know, business objects. What's a record for me is a dealership for a car dealer. It's a patient. And actually, so scroll is a huge problem. And at that time, around that time, Mark Zuckerberg, like two weeks after we decided to do this, Mark Zuckerberg came on and said, the biggest mistake we ever made is betting on HTML5, right? And you don't, that is something that you don't need. The problem was, so Sencha, the guys behind EXTGS, actually went back and showed that you could build a performance a Facebook app. And the thing about infinite scrolling is that if you keep appending to the DOM, that is what causes it to slow down because you have a lot of elements on the DOM. And if you look at how table views are rendered on the native side, you basically have, say, 10 or 20 cells and you keep reusing them, right? So, your depth doesn't go beyond. So, if you look at all the infinite scrolling, anything that actually does perform an infinite scrolling today, they actually reuse these cells again and again. And that is what confirms it. If your scroller isn't doing that, you'll always run into garbage collection problem and that's just the wrong way to do it. So that is, if you're worried about scrolling, that's what I would say. And that's how they are implementing it. One more question. Any special reason I should switch to famous compared to already set 3.js as 3 renders? 3.js. Ah, okay. So 3.js is WebGL, right? And so the first reason is not every browser has WebGL. They have a CSS 3 renderer. So, no, it isn't. So, I'll tell you how we evaluated. It was more like in a post WebGL world does famous have a thing, right? Does famous have a story. And I don't know much about 3.js, but I think the language is like meshes and things like that. Really, the way we would evaluate it is how do both communities respond in creating components, right? So if you look at IOS versus Google's latest material design and one of them you press a button and it goes down and the other one it comes up, right? That is not the kind of stuff I want my engineer spending time on. And that any community that solves that, any framework that solves that going forward will be it will be the winner, right? Because no one has no one has ownership of something like matrix multiplication. Both can do it. Both will do it, right? And so basically it depends on what are the components what are the widgets that you can build. Can you like alleviate the fact that if I want to build a basic app, I don't have to worry about the discrepancies between IOS and Android because they are diverging. Guys, this is the last question because we need to move on to the next talk. I have one. Yes. Sorry. Yeah, all right. So that's the last question. Yeah. As per the said like if you use more translations, 3DR2D it takes more, it goes to GPU and drains your battery. Right. Okay. So if my app has got so many translations like that, how do you balance such situations? How do you sorry? How do you balance such kind of situations so that user never come to my app, drains his battery? Oh, how do you design for like the not running battery? Yeah. I would say benchmarking, right? Like, so one of the things I want to do is I currently have an iPhone, my next phone will probably be like a low-end smartphone only because there's a whole new like billion users coming on that. I would say use your app and if you are pained by it you would do it. In terms of technically how you would do it, you would try to reduce the number of animations or you would try to reduce the the number of renderables, right. So maybe increase font size or things like that. It's a trade-off that you have to make based on what your application is but I would say always to me at least battery life matters way more than whether I have a really cool animation going because I can actually keep track of the fact that, oh hey this app is going to GPS all the time so let me not use it because I have only 30% on my phone so users will give you feedback in that manner and I would personally I would cut out the animations if I ever found it was draining battery and the way I would measure it is to just use it. Okay. Thank you. Thank you all very much for your patience. Thank you.


Hello everyone and welcome to another episode of Code Emporium where we are going to talk about some Python libraries that you should be using as a data scientist. Python has been breaking the ranks as one of the most popular languages out there especially in terms of job opportunity. Studies have shown that about 75% of all jobs open as data scientist positions require Python as a prerequisite. And so this video is going to be focused mainly on Python libraries that you'll be using as a data scientist. Also I have two years of experience as a data scientist and I can tell you Python is indeed important and I'm hoping that my experience could also help you and others like you out there too. The way I'm going to be structuring this video is that I'm going to give you certain points on different parts of the machine learning pipeline and then also give the corresponding Python library that I think is the most useful in that domain. And then we'll talk a little bit about details from there in each case. Before we get started, please do give this video a little thumbs up because it'll help the algorithm and spread the video to people who are like you and would like content like this too. Also if you like what you see, please do consider subscribing. We now have a Discord server so I'll be super active on that. We can just come on, hang out. We'll talk for a bit on just stuff that geeks talk about in artificial intelligence. It's going to be super fun. So please do check that out. The links are in the description down below. And with that out of the way, let's get back to the video. So the first phase in the machine learning pipeline is data wrangling and the most important Python library in this category goes to pandas. So data wrangling is the process of essentially manipulating data, either the structure of table data or actual data within the tables themselves. And typically this data is in a tabular format. And if it is, it can be easily manipulated with pandas. So pandas treats tables as a built in data type called a data frame. And with that we can perform operations that include like changing structures and also changing values pretty easily. It's definitely one of the most important Python libraries out there to check out. And so I recommend you do learn that if that's the first thing you ever do with Python. The second phase of the machine learning pipeline we're going to look at is data visualization and the top contender here goes to matplotlib. And there's also some secondary and tertiary mentions of Seaborn and Plotly. So data visualization is essentially basically changing all the tables and numbers into nice infographics and pictures because that is super important since pictures speak over a thousand words. And especially when you're talking to stakeholders as you would be in data science, you're talking to people who just don't necessarily have a data background and will be easily overwhelmed with just large numbers and instead showing them a nice cute little visualization will go a long way in pushing your point forward, pushing your agenda forward and they get to understand exactly what you're talking about without being bogged down by the numbers. Also data visualizations are super important just for you to understand exactly what's going on, be it bar charts or line plots or whatever it is. Matplotlib is a great Python library since it supports all of this from bar charts, line charts, box plots, anything you'd want and anything you'd need. I have a special mention for Seaborn because it is built on top of Matplotlib and essentially it allows us to do the same things that Matplotlib does but with less code essentially and also it has good built in visualizations that just come out of the box that I kind of do like for certain cases and so I throw in Seaborn whenever I can. I also mentioned Plotly but Plotly is great for creating these interactive diagrams and interactive charts. Basically you might have seen these charts where you can kind of hover over some parts of it with your mouse and a tool tip pop up just like comes on the screen and you'll see some additional information. It's great for these interactive charts and I've also seen it in a couple of business intelligence tools too. So definitely do also recommend checking out Plotly for just some additional fluff in your data science visualization arsenal. It's pretty cool so please do check it out. There's also a ton of other data visualization libraries out there that I have not mentioned but I haven't really used them too much. You can always explore them as when you wish but I've just thought I'd give you only the most important ones. Moving on to number three in the machine learning pipeline that is feature engineering and the most important Python library in this category goes to stats models. So feature engineering is essentially trying to figure out what features can be used in your model whether it's a classification model or a regression model. The idea here is to try to convert and make sense of that data that you have in order to extract certain features that you can use to input to a potential model and here stats models can help because it allows you to come up with very simple models like logistic regression linear regression super easily. Essentially what you would do is if you have an idea of a feature in mind you would try to use that as an X variable like an input potential feature and then the Y variable would potentially be the target and you can try to find out like the correlation between these two variables within just a few lines of code. You can then make decisions on whether to include in your model if you see some high correlation with it or try to increase the complexity of that feature maybe by using square terms of that cube terms of that feature or a log or a square root or something of that sort and see if it actually has still some correlation with the output feature. If it does, maybe you decide to include it. If it doesn't, it's probably not worth it and so stats models can be super useful in just engineering features for your model. And now coming up on number four, we have the modeling phase and the most important Python library for modeling goes to scikit-learn as there is no surprise here. Scikit-learn has always been touted as one of the go-to libraries to just go and model things. You want to create a model, you use scikit-learn. But something that is underrated about scikit-learn is the ability to create machine learning pipelines. Machine learning pipelines are essentially end-to-end flows and not just creating a model but also from the creation of pre-processing stages. It could be standard scaling or encoding of your variables to then piping it into a machine learning model to training that model and having a trained model in hand and then also making sure that all of your data is in the correct format. This entire flow can be easily coded out in a very reproducible and reusable manner using scikit-learn. So what essentially that means is you can take this pipeline that you create with scikit-learn for a specific problem and then you can transfer it to another problem literally using the exact same code. And all you would need to do is maybe just change the input data and it can be used super quick and super easily if you've just built one model out completely. And I feel like this part and this aspect of scikit-learn has not been getting enough traction. And in order to address that concern, I actually created a video on the machine learning pipeline to explain exactly how scikit-learn can be used to create such machine learning pipelines and I encourage everybody to actually code out their pipelines keeping this in mind. So do check it out after this video. Coming up on number five of the machine learning flow and we have model interpretability and the most important Python library in this category has to go to SHAP. So model interpretability is essentially taking a model and trying to determine what features are actually the most important to that model. Now, SHAP is a great Python library because it also employs reusability like I mentioned in the machine learning pipeline section which was number four. By reusability here, I mean that we could use the same code using SHAP to establish the model interpretability of like a scikit-learn built-in model and reuse that same code for establishing the interpretability of a customized PyTorch neural network. It is all the same code. It's literally a copy and paste with just a different model in it. SHAP is essentially a library that uses game theory to assign feature importance to a set of individual features and you have like a number of these features that essentially compete for model importance and because it can be treated in a way that is very abstract from the actual model itself, it can be used to interpret any machine learning model out there. And in fact, it is so reusable that I've created an entire video just on SHAP and just how powerful it can be using some example models for interpretability. So if you're really interested in how to expand your vision of model interpretability, please do check out that video. As a number six here in the machine learning flow, it's kind of a bonus and I've included SQL processing and I've given this vote to Panda SQL. So typically you don't really need this for the most part because maybe let's say that the way that you're getting your data is typically from a data warehouse. So you'd write queries to query a data warehouse and then you would process that data with pandas and then moving forward with the machine learning flow. But there are certain situations where you might be reading data from a CSV file and maybe you wanna process everything within pandas itself from the very beginning. And it's just sometimes it becomes a little tough to actually just process data using Python pandas commands. And it's just easier and more intuitive to like create group buys, aggregations and just more complex operations with SQL code. And so Panda SQL allows us to manipulate data frames with SQL code. And that's why I've just included it here. So it can be useful in some cases, but it's definitely not a 100% priority. Should be easy to pick up regardless anyways. And that's all I have for you now. I hope you really did like these tips and like these libraries. Did you learn something new here? Did you not learn anything new? Please let us know in the comments down below. And also please do remember to give this video a like to spread the word out. Please do subscribe. Join the Discord server down in the description below. Like I said before, we're gonna have a lot of activity going on there. I'm just setting it up now, but for sure, I'm sure that we're gonna make it a big fun place for all geeks to enjoy. And until next time, I will see you very soon.


All right. Good morning cyber traders. Welcome back on this lovely Thursday January 16th as everybody doing good to see you bones. Good to see you Phil clip everyone Chuck Cheryl everybody all you cyber great cyber traders.  First of all, I'm on a cover and Talk about what happened yesterday.  I don't really like what happened at a pre-market pre-market already the CETX But we've got some really cool stuff going on with that with some of these stocks. By the way the QD I don't know if you guys just saw it. There was a 800,000 share Seller out there and guess what? I think he just pulled his order It just he just pulled his order hold it on. Anyway, that's not like a great short that's been happened with that one.  He wasn't on he wasn't on the NASDAQ. He was on EDGX was on another ECN out there pretty cool, right? By the way, did you guys get a chance to watch me on on NASDAQ said NASDAQ's TV station yesterday? Everybody had a chance to we set that a big promote the big emails of streaming live rich. Did you say it? Okay, great, great It was fun being there. Actually, they just invited me But I think we're gonna be bringing the closing bell on the on the NASDAQ. So NASDAQ is starting to realize that they really are trying to push this level three the total view they realize how important it is their whole business model is is basically surrounded by that and you know now they want to be able to do a lot more and Promote people about it. So it's gonna be a lot of fun. I mean, I'll tell you guys a little bit later about it I want to get right into the actual trading part of it because I know you guys are really Ready to start rock and roll because there's some really nice stocks But before we do that, let's talk about what happened yesterday because there were a couple of good stocks I did make some big moves. I want to cover them really quick. I want to start off the SDC It keep going from yesterday's morning. Oops, let me fix the chart right here So that one you could see it had a nice little short It went from, you know, 2410 it dropped all the way down to 2380 and then weren't right back up But she's starting to trend down making lower lows So that one I would probably keep an eye on it still today as they're looking at the short Remember, you want to be a good? Oops, I spelled it wrong. You want to be a good day trade? You better be a good swing trader. Anyway, here's the other one right there I'm gonna keep that SDS on the chart because I'm still seeing a making lower lows. Let's pop over here in the SDC This one right here was probably the best stock of the day yesterday. This stock just literally ran from Was at 11 and within an hour ran all the way to about 14 Stock is still strong. Listen, she's up about 3% so far. She's got some really nice level Iceberg orders out there. So we're gonna keep the SDC back on the watch list. That one is pretty good I kind of like that one too. She never really backed off. She was also a pretty good nice runner in the afternoon Just be careful because the stock if you look at it remember phase one One of the biggest things we teach you in our classes is not how to make money We teach you how to stop losing it and the number one biggest thing you got to learn how to stop losing is Not the commission charges now you get a lot for free is the spread the spread the stock had a very very volatile Spread and that was the only bad thing about that. You had to be cute kid be careful of Another stock that's gonna go back on our radar including for today again is the og I That one had a really nice move had a couple of nasty shakes here But that stock you could see it started this morning had a really nice pop went for about 250 all the way about 320 she's really she's at 330 right now. She looks like she's filling in the gap right here She could probably could test the whole way up in the the 375s, which is the next resistance but this stock looking here on the right-hand side 13,000 share bar 5,000 chair by not a lot of cello. So still looks like we still got a demand on the og I So that one you know set up a lot. It's only up 7% but it was up a lot yesterday I'm still throwing that back on our watch list No stock yesterday. The QD is what we just mentioned earlier So that big iceberg order that basically canceled his order. He'd not get filled I'm looking at the level 4 version of the platform on my trading system and Like I said, he didn't get filled looks like I just canceled the order, which is I'm not still trusting that I still don't trust that stop. All right but a Couple of good things that rain yesterday, too I want to go over it and nugget and J and Jnug But other than that, let's go get right into what's happening this morning now We all know what happened yesterday. We finally busted through the 29,000 So for all remember I keep telling you this for all those haters out there, okay? Short the market. I got people all day They come up to me and they keep saying you see the market's gonna go down two reasons why they you know And the main reason why they just got so jealous they didn't get into it And they're hoping that they see so many other people making money doing it I just tell them listen if you really think it's going down you missed a rally just short it Just short it and they're like and I keep saying this they keep saying to me How do you sure they're like, you know how you short take my class? I'll teach you how to sure obviously you know anything about the stock market If you don't know how to short they're like, isn't that risky? I'm like Listen, you want to know it's risky getting in the car drinking and driving. That's risky. You think trading is risky There's a lot more things risky than that. So anyway, let's go through the watch list and see what we got going on In out in our watch list. So we got this one stock like I told you the the C the C Etx right here The only thing is like, I don't know in pre-market. It's just not really trending. You know, it's not really doing that well So, yeah, I want to see how she opens up. We still got the the the sig the SIG This stock right out of the gate this morning If you got him when he was supposed to at 8 o'clock this morning you're doing fabulous You probably should be in about 26 right now. It's at 28 stock is breaking old-time highs right here You can see it right there beautiful stock That's not right there really really like the SGI and me like I tell you it's breaking 52 weeks highs right here And it's still strong the only bad thing about this stock is that it's it's got a very very ugly spread Okay, it's kind of it's kind of like Stopped right around in nine o'clock, which we all know what happens at nine But she's kind of panning out right here and kind of like holding steady There's another stock that's making a big move Xpo, but the only issue is this we're not trading a 98,000 stock. Okay, that's it. That ends it We got another one right here that also will not too expensive stock was you know Was a little expensive at one point, but listen big support here back in July major resistance that you know back in the end of September spit came back here to support levels again. She's trending up NGI also is gonna make the watch list hundred thousand shares got some good orders out there on the loser's side Like I told you the QD we're gonna keep an eye on it trade already to point two million chairs But I don't trust that big order out there. He didn't think I didn't see him We all saw him out there So we're gonna keep an eye on that one another one that was big yesterday But you know and I think it has a lot to do with the China deal But she's starting to back off you could also keep an eye in NiO This thing was a pretty fun stock yesterday a lot of you guys did well on it But you kind of backed off so That really bad does it I mean didn't really see too much out there. You got this BK which is 300,000 shares stock is on a downtrend. You probably get it short, but remember it is $46 BK And that's not Burger King. Just let everybody know All right, so And that's about it. I don't think I have any more ACB and that one's pretty good. I remember we trade that a few times. It's got good volume. I remember it has a good nice little spread ACB is not terrible. It looks like it's making new highs very cheap stock, you know what it's a level one stock ACB all right Josh is saying apex a PEX is also one to watch. Yes, that's a great call Josh We if you guys remember this we trade the stock not too long ago right here Remember the stock has a unbelievable great fund short squeeze. So don't be getting cocky Remember we trade the stock went from a dollar went all the way to 220 which tested resistance back in September and came right back down to 70 Cent so a PEX we don't listen Don't let the inexpensive stock fool you the stock that plays some nasty shakes But remember it was a fun stock and if you did what we taught you in class if you look at your journals Go check them out and see how you did in it, but that was a great call right there Josh Nice trade. Alright, so pretty much got a list right here Let's go out there and try to have some fun and guys remember today We got a couple events going on we are gonna be hosting an onsite Free event here here in the Long Island area. So if you haven't registered Feel free to kind of like come out there and probably got a registration So we're doing a big event tonight at 630 here on Long Island So if you live in the area look forward to seeing you guys gonna do a little do a nice little class for everyone Something we do once in a while here, you know Not just webinars, but we do a lot of onsite stuff and then also remember today at 12 o'clock We have open house. So if I know first, I like to thank Michael Michael went on Facebook and went out there and sent a really nice Posting of how much money he made an embot And you know, it always sounds better when you guys say it and not me You know, I mean that's because you know what it kind of really shows you that it's not about this is not the me show I tell you about that. It's that you guys train together. Our job is I'm just a messenger I'm just here to teach you guys how to not lose money So we can't make money together But but going out there and putting those posts out there We really really appreciate it because you know, unfortunately, I hate to say this a lot of people are very negative A lot of people got ripped off from a lot of schools out there and I get it.   Thanks guys and That's the when you be on well 365 summit. I'm gonna be on Monday. I think I'm on Monday or Tuesday I mean it's for three days, but we'll send an email on that. You should have gotten an email on draft So that's a really really big event. Listen. I know you guys can't be there for three days But listen, it's a there's a lot of great speakers So just that's one other place that you can help support us go out there and being in that trading room That's that's and register most importantly We sent an email make sure you register for us because they do that does help us a lot that you guys also Contribute and register for those events. Thanks everybody. Good luck today. Sorry for wasting too much time talking about it but I think it's something very important that had to cover and in the meantime We got a lot of good stocks that are moving this morning. Let's see if we see something We'll say something once again, not everything is moving But if something is we'll go out there and share it with you. Alright, good luck everyone. Happy trading and see all the trading room


రోకుముఏను఍ర� Bridge పత్నోЛోయ్D మునabisొ� ré dersయో baggage ఐ�ena dľaäολ Cheers క veget didi ... స౧నంనేIdzz ప౎ధథికALI య్ళోహియిసురం Bab치는 it టక్త్ పతధవంనీ turf implement న్ట్ఘ త్రంలేనిద pretty Are you capable that a woman can look at you and tell you, these are my inspirations, you have created a platform, the girl is so confident to tell you a lot of stars. Number two, will I always demonstrate my affection, not expecting her to take my love for granted. There is a way a man must carry himself, and you can be jovial, but nobody can take it for granted. You can't disrespect me, I will finish you, I'm sorry. I will laugh or joke, but you must build a personality in a way, the way you carry yourself, jovial, very social, but nobody can take your love and your personality for granted. Men must ask themselves this question, will I try to see things from her perspective, as well as my own, to avoid becoming set in my ways. It's either my way or no other way, that is especially a choleric individual, no, like Tike Menza, no, calm down.  Can I lead interesting discussions of important issues without it ending in an argument? A man must develop the capacity to do this. If we do have a misunderstanding or a pervish outburst of irritation, will I put it behind us settling the difficulty one way or the other, or will I suck upon inviting the problems to return, always guilt stripping. No, no, that is a root, a red flag or a red story building. Will I make allowances for irritability brought about through over kindness and a build up of little house annoyances pretending not to notice it.  No, you need to know that something is wrong somewhere. Can you handle this without it turning into a fight again? Will I inspire her and take an interest in her hobbies and in her more ambitious ventures that are necessary for her happiness. Some men are threatened by the advances and the progress of a woman. God created her with a star, with a certain unique impact she must make in the world.  Allow her, you may have a first degree, she may have a PhD, but she must respect. There is a way to handle it and it can be fine. Don't will you be that husband to our daughters. Will I take an interest in her clothes, show her my appreciation and pay, hear the little compliment and the attention that I did in our courting days. All the men are telling her the nice things and only you they must beg and make an altar call before you say for once, this attire is nice, which man are you? Will her life be enriched, her interest broaden and her happiness and general well being increased by marrying me? Can this lady you want to date or marry, can she become better just by marrying you? Will I keep loving her as the years roll by and changes of child's birth become glaring and age having its toll on her? She is to have a flat tummy, project after four or five kids or three. When the breast is now dropping, the stomach is now different. Sir, will you still love this girl that is looking like a rose flower today?