I'm Frank. What do I do? Well, this is me hiking. So I'm an architectural drill instructor. So that means I talk a lot and I nag a lot about building larger applications. I love writing JavaScript, haven't figured out why, but I like doing it. Also, I am product design obsessed, big data juggler that just get some buzzwords in there. And also a game dev enthusiast.  So I already had like four cups today. So if I'm shaking, it's not from distress. It's from the coffee. Okay. My background, well, like I said, a freelance at the moment. So I've been around a lot of places. So I've been in very small teams, meaning me, myself and I. Also in bigger teams, enterprise, I've done vanilla. Yes, I've done frameworks. Again, like WebGL, game development, converse audio. I've done pretty much not everything, but let's say I have a broad spectrum of what JavaScript is and I'm going to talk about how you can scale larger JavaScript applications. So first of all, first question. Who writes JavaScript here? Okay. Who writes Angular? Okay. React. Okay. Purely vanilla. Okay.  People know what they're talking about. Okay. First of all, scaling. Everybody thinks scaling is for big teams, for enterprise, for like 30, 40, 50 people working on one team. Well, I don't think this is scaling. Scaling is the moment you start working with more than one developer. So one developer, more than one feature, more than one week of development. This means doing more than what just one people can think of. Why do you want to scale? Well, most of the times, well, if you want to scale, what do you need? Well, you need a system. Why do you need a system? Well, you want a speed of development and you want predictable results. What is a system? Well, a system is a, let's say it's a collection of patterns that help you create predictable results. And most of the time, this is a combination of hard and soft systems. What I'm going to talk about is, first, JavaScript as a language and what are my systems and what I learned. Then second part is structural patterns. How did you go into structure your application? This will be the hard part. So I think half of you guys will be asleep after this part. But then again, we'll end the talk with some lighter stuff, some soft systems, some non-IT stuff. Okay. Questions here? So no. And at the end, you can all ask a question. Okay. First of all, JavaScript. Well, JavaScript as a language, like you might have noticed it's, there are some bad parts and some good parts. So first of all, and this is one I want to repeat a lot, is don't forget that JavaScript has a pass by reference. Who knew this? Okay. So quickly, quickly.  It is pass by value. The moment you start like passing around objects, it's passed by reference. So before you know, you will be editing like one object here in the application. And on the other side, that will be also updating. And it gets very weird results. Just remember, JavaScript also has prototype. Anybody uses prototype really? Okay. That's a minority. Well, I don't like prototype. I like to avoid it because I have, well, later on you will see why I don't like it, but I don't like inheritance in an application and in general. This is a very strong opinion, but don't be, don't fear. Third one. Okay. This is just JavaScript. Not the number is toxic.  No is an object. And most important one, numbers are floats. This means that you can do like price calculations or anything in JavaScript. There are libraries who help you for this, but it will give you very strange results in rounding. If I'm going to quick this, you can later on watch the slides and just go over them point by point and then reference a look them up on Wikipedia. And this is again, a sync by nature. And this is something I noticed. And why I'm added the slides in general is a lot of people don't recognize or know that JavaScript is very a sync. So there is no guarantee that each line will be procedurally printed out or run. If there is one call like to a backend and that's not returned with an instant, instant, instant, it can just skip that line and just go to the next. Why do I need to slide? Well, next question. Who of you ever read JavaScript, the good parts? Yeah. That's a minority of the people who are using JavaScript. Who of you say not a good part, just studied the language in general, just the pitfalls or anything that's... Okay, so you're writing JavaScript and you don't know what you're doing. And then you get the message, this is... So I never told you I was going to be nice. Okay, step one. So you want to build scalable JavaScript application just by the book, the good parts. It's this thick. And I think only the first half is about the good parts. So the rest you can just skip and ignore and do not use unless you really, really, really know what you're doing, but even I don't know. Okay, second part, building an application. Fear the global. Again, this is same that Crockford says, don't use the global. This is a very common practice. That's a lot of applications, mainly in Drupal world use is like, okay, let's just create window dot, put the data there, and then on the other side of the application, we can just edit there and just use the global as an environment variable. Well, this is a bad practice. This will have give you problems. What will it do? Yeah, first of all, namespace collision. So what if your application, you implement another third party who is in the same namespace as you? Well, you have problems. It's also way too easy. So it will be too easy to have bad habits. And then again, the bad habits was like using a data, multiple parts of your application influencing each other when they shouldn't. Most important one, watch out for accidental globals because you can create globals without even knowing. So if you forget the var before any variable, your compiler, your browser will just create a global. So you can be like editing each global. I had this problem with low dash. I use modules, but I accidentally forgot to var it and that the application started crashing, crashing, crashing. I had no idea where to look and I had to go to every line of my application just to figure out I forgot to var. It happens. Okay. Yeah, this is just going over the language. So who of you who write JavaScript uses this a lot? So this, this. Well, figured out you probably shouldn't except if you really, really know what you're doing. So why is this not a good option? It's mainly for security. So if you have an object, would have a... No, I don't have a detail. Okay. Why don't you want to use this security? If you have the file and JavaScript, you have the functions like call, bind or apply which allow you to change this. So if anywhere within like say you have this function and it uses this, I can change that. So say this gets token or this get function. I can just pass in the, then change this object. So I can like hijack. I know this is security stuff and I should have had a slide to explain this. Okay. But except from security predictability. How many times I've been through a JavaScript application and it was like, yeah, this dot get, this dot get this, this dot get. And then by the time it's this dot name, this dot name, you're like four levels deep and you have no ID. What's inside this, where it's coming from and it's just changing all over. Anybody has recognized this problem? It's a mess. Again, avoid the call and once you start using like this, you have to start to be sure everywhere. You cannot use just regular functions. You have to start using call, apply, bind or if you're using ES6, the fat arrows that why you're forcing the new this object. And again, again, it gives you weird errors if this, if you would be, if you would be using like this inside a, let's say in X HR request, it can lose that context again and then it will fall back to the window. So you will, no, it changes a lot. So how do you solve this? Well, don't use this, just use private variables. So whatever you declare within your function or within your module, just bind it once. Or if you want to use this, just type once for that equals this and this is solved. Okay, where does this make sense? If you're writing like TypeScript or writing like ES6 classes, there you have of course the Java thingy, not the Java thingy, but they use it a lot in Java. Is the, you have classes and there you have always, this is referencing to the current instance. But again, this is not security proof. Like in Angular 2, they use TypeScript a lot and even Angular had to fix this problem. And I have to stop saying this. Okay, an easy one. Okay, who uses gulp, grunt, webpack, any? Who still uses grunt? Ah, there are better tools on the, well, if it works, it works, but again, keep it simple, use a small building tool. But an important part is seen with a lot of clients and a lot of teams, teams I joined is I enter and they have like this very big grunt or gulp file and nobody understands it. And then you ask who wrote this? Well, we copy pasted it from somewhere on the internet on Stack Overflow and nobody has any clue how it works and if it breaks, they're fucked. So please, I cannot advise you this, just write it yourself. It's a small documentation, don't do, and this will also hold you back from like writing these over complex builders. Again, keep it simple. Even if you do building tool, I've seen this way too much in teams is symbolic linking. Well, there are copy, there are other ways, symbolic linking, I mean, there's one folder with some assets here, some folder there, there are copy functions, there are many solutions to this, but not symbolic linking. Again, why do you want to use a building tool? Well, you can run automated tests, you can run quality checks. Again, you can, I think everybody knows what the benefits are, optimize and minify. Yeah, do not overdo it, keep it simple. And again, do not copy paste setups. This is very important. Next, this is one, this is a slide especially edited for the Drupal con because damn, you guys use way too much jQuery inline templating. So if that's, I know, mainly in Drupal 7, there was no template engine. So everybody uses jQuery and that was fun, but then you start really like this big concatenation. So if this happens, then, okay, then now add this string to this bar, then if then, if then, if then, and at the end, you just don't get it. And if you want to change one little thing to it, it just breaks. So use a template engine. There are many way and many out there. There is like moustache, you have virtual DOM if you want to be fancy. React is kind of a render engine, but it does a job. You also have now ES6 template strings. Another mean that somebody pointed me to because I was writing everything also in line is use template files. Why is this important? If you start using like a template engine, you create nice if, if, if, but not everybody writes the JavaScript or whatever jQuery framework as well as you do. So there are designers out there who don't write JavaScript or jQuery, but they still want altered like just the HTML of a template. This I don't have to explain to a Drupal audience with the whole twig end, but just write it. Okay, this is important one for me because again, I was bashing on the dysfunction. If you're writing a JavaScript application, keep it simple. That's again, this goes against the advice I'm giving about the prototypes. JavaScript has the most awesome thing that a lot of languages don't have. There's function first class citizens so you can bind the means of function you can easily bind them to object and you can do everything with them. So just use literal objects. What does a literal object mean? And I don't have a example for that. Well, well, roughly literal objects means you can, everything is just an object. If you just say like open the square bracket, I know the, I don't know what the brackets, the brackets are, you have an object. Easy, the fun part about this is that within this object, you have a, like a private scope. So anything you declare inside that private scope is private for that object. Fun part is, that's very simple and particular code.  I will explain this in the next slide. So, okay. If you thought this was a hard part, well, let's start looking at the structural patterns. So once you mastered the JavaScript as a language, it's fun, you can write strings, you can do fun part, but then at a certain point you will hit a very hard wall because you don't know how to structure. You have two options then. First, you start using a framework that solves all these problems for you. So if you recognize any of the next stuff, it's probably because you use it in a framework like Angular or React, React is not a framework, it's a render engine. So, or Amber, or you can be like me and get phonetic about it and research what design patterns are and try to write your own frameworks and then in the end learn that it's a bad decision. So, but I learned a lot and that's why I'm presenting, making presentation about it. First of all, if you're writing any JavaScript today, there's no reason to use, do not use modules. Who have you written modules in JavaScript? Okay, modules are like little containers like a clover, they're like the, all the good things of a class than in a JavaScript. That's the thing, just how these little containers that facilitate modular code. They mainly used first, I don't know, but they mainly used in Node.js. Fun part is, you can use them also in the, you can use them in just in the browser. What are they? Well, easy as this. This is just a module. What does it mean? Well, you have, it's just a function that has functions and that you have a very defined return. Nothing more, nothing less. This is a function. This is something you can export if you use a module loader. What does this give you? Well, this gives you the opportunity to write private and public functions to only reveal what you want. So if you look at the bottom, I could have written any private variable, any private function I have wanted. I would only, at the end, I will only return what I need. This again, this is a very opinionated way of doing this. So you can also just return or just add it to my module, but I think this is a very clean way. This is the revealing module pattern. What else can you do? Really private variable. So this solves the security issue and it's highly testable because you have a very small snippet of code with an input like params, a couple of functions and that's it. So it does not have any knowledge outside its scope. It shouldn't also. And if you combine this with not using global, it becomes a very structured way of working. Okay. What next? What does it give you in structure? Well, it's a little bit, yeah, it's a little bit like having these little containers of code. So this is an example of an application where I have a very simple JavaScript, web audio player. So I have a small module, which does the audio, a small main. Every application has a main. So you're just whatever loading the services you need, the data and you're creating the elements and you're including the audio module, the controls module and then the main module doesn't know about the controls about the play button or the progress button, but it just, the controls will include the play button and the pro. It's a way of structuring your codes. For example, I'll leave it on, I will show this. Important and this is very important. If you start writing like modular code and this little modules, is do not access the globals. The moment I've seen this too much in third party libraries that I use and I go to the codes and what they do is like, they start accessing the global object and then you just beat in the point of using any code encapsulation. And then they start extending the globals. So yeah, important part there is also alter input params, do not do this. So if you go back here, I am using params. So just data as in a module, I would, if you want to stay sane, respect your data you get in from the top and don't try to alter it. If you want to alter it, copy it, do it. Just again, watch out with the pass by reference so you don't know where the data is coming from and it's the altering and before you know, you start screwing up your own application. There are solutions and later on I will discuss those. What's super long modules?  And this is very hard also.  So I constantly refactoring, rewriting my application just to be a little bit more structured, a little bit more encapsulated. Okay, so what do you do with the modules? Because this is fun but my browser does not do a lot with this. So okay, I have a function and so I, so you use a module loader. Since ES6 you will have also have modules system so it's in there but that's there are sync modules, of course. So I prefer using browser file but lately I've been using a lot of webpack. That's a good reason for that. First, they do, what do they do? Well, they help you load the modules so they load all the code and then they start gluing everything together. So okay, this module needs this module. Okay, let's load that code and let's inject it here. It resolves the dependencies for you. So again, import, if you import the code, fun part is, so if I would, for in the play button, if I would need the play button in my controls, the only thing I have to write down is import and then the path of the module, that's it. Then the module loader will just resolve this for me. Whatever you want. So you've got the required yes which is an asynchronous module definition. This is, as the name says, browser file which is common yes, which is mainly like no yes way. So import, export, like no yes does it. So one of the main benefits of a module loader is so you can have very large folder structure with a lot of dependencies here and there. In the end, you just say browser file, webpack or whatever, build my application and it will just squeeze everything together and get it in the right loading order and give you one small file that is usable and that can just be thrown in there. Okay, and why do I use webpack lately? Because again, like JavaScript, there are multiple standards, hooray. And sometimes I have this application, I write mainly common yes and some third party services. I third party plugins use AMD, webpack solves it for you, it's just universal loader so you don't have to care about it anymore. Most important part is when you start using like browser file or webpack is that you can link them up with NPM. So NPM is the package manager for node so you can start using all the node modules also. The only thing you have to do is NPM install this module, of course NPM in it, whatever in your project, NPM install this module and next thing you have to do is just write import this module and webpack browser file that will just solve that for you. So you get a very modular code. For example, if this is load dash where they have every function that they have, they have it as a NPM packages separately. So you don't need to load the whole load dash application at once, you can just like load one function and all its dependencies.  So it's package manager, you do not need to read the intervention wheel and again, easy deployment and testing.  No more uses of power, no more including the library in the Drupal libraries, just all of everything is perfectly packaged there. What would this give for our example application? Well, let's say if my play button would have, would you be fancy and use virtual DOM and load dash for each, for example, the only thing I would do is play button import virtual DOM and play button import for each, which would not look like this, okay. Okay, that's it, this will compile, the browser file will solve this for me, I will have one small build which is minified. Again, this works together with something like grunt, gulp or anything you want. Okay, I told you this is gonna be a lot of content. So you have dependency injection. Who knows dependency injection and use it? So it's Drupal, who used Angular? Not much, you're not Angular lovers. So Angular uses a lot of dependency injection. Well, dependency injection is a very, very fancy name of, like, well, in JavaScript you can, is a very fancy name of injecting your dependencies. So for example, I have a library, the mediator, which we'll explain a little bit later, and I'm injecting this in this module. So if you look at it, so see at the bottom is just a small module that I wrote, it's equals a function. And then I pass in as param, parameter, a mediator. What is a mediator? This is an event system. This can be come from ever, this can be just a jQuery event system, this can be whatever event system you are using. Here I'm injecting it and I'm using it. Fun part is you can, like, use different mediators or have multiple instances of a mediator for multiple parts of the application, but you can still reuse this small part of code. Of course, there are pro and cons to using dependency injection.   Limiting the guilty knowledge. This means everything that the module needs to know needs to be passed in by the parameters. And again, testability. Why is this, and this is the main pro point for dependency injection is testability, because it does not get any knowledge outside its scope, so you can easily test just get the, and like, if it has like two data services or external services, you can inject like easily mock data. So you have everything under control and testing becomes a breeze. Of course, there are really problems with that. First of all, you have tight coupling because you have to inject everything that the thing needs. So dependency injection is fun in the beginning of your application, but before you know the button, the one button needs like 10 services. It needs to know about the audio. It needs to know about the render engine. It has like this, I'm betting that Drupal has this problem that Angular has this problem, like you're injecting like 15 parameters or services or whatever render engine you're using.  Another problem is circular dependency, but I know it's a lot today, but if you would ever start using dependency injection and you start having problems with a lot of dependency injection, do not use service locators. Just remind, remember to store this and this will help you one day. Inversion of control is the way to go. I know these words on say much at the moment, but just remember it. And this is my favorite, yeah, I've come to the point where I have a favorite pattern. This is my favorite pattern. This is the mediator pattern. And what does this solve for me? Well, we're almost there. Well, let's say I have, again, same application. I have a button at the first part. If you go back, the play button, the playback rate, progress bar, this is an audio application. Had a tight coupling with audio elements. Well, later on the client wants a video element. So I add the video element and you start seeing that the playback rate button now we need to know about the video, about the audio. You're starting to get a lot of dependencies. Well, this problem has been solved a lot for years in the UI by the mediator pattern. What is a mediator pattern? Well, it's this. So there is no direct communication between any parts of the application. Trust me, this is very hard to write, but once it works, it's awesome. So what does it mean?  So play button does not know about any of the rendering, does not know about what audio element or video element is attached or what state it is. The only thing it does is, am I playing or am I not playing? If I want to play, I send out the event play. If I do not want to play, I send out the event pause and I change state. That's it. So I can have 20 buttons, they will just update. The only thing they're going to do is send out events. What will this mean is, I can change YouTube audio and video whenever I want. So on the fly, I just, the play, they like say start playing and then the audio element, I say, okay, now I want YouTube. YouTube start playing. Well, the play button doesn't know, doesn't care. Same for the playback rate, progress bar or the mute button. They will just keep on sending events out. This is also, again, very testable. No, of course, there are pro and cons. That's with everything. That's life. The biggest pro I got about this was debugging. Because it's like every, you can, especially if you use this for the UI side. So this is not for like sharing data between parts of the application. This is more of capturing the interaction of users. So, but you can start like debugging and printing every event that happens. So whatever, and you can do it to your console. So user starts clicking, for example, audio starts playing, event goes audio play. User presses a button, click, event goes click. So you're getting a backlog of all the events. So wherever the error happens, you will see what the last event was before the event was sent. Easy. Regression testing, same refactoring becomes very easy because none of the elements, none of the modules or any small part of the application have knowledge of each other. So you can just add them, throw them out as long as you expect the same event code. I use the same event messaging. Fun part, this is for the marketing department, it's measuring. So you can really easily like hijack an event. So if you would add like Google Analytics here. So the marketing department wants to measure every click on the play button.  So say the marketing one every play. Well, you can do is just listen to the mediator and listen to every play event and then just Google Analytics this. Every time somebody clicks anywhere, just Google Analytics this. You just have like this one event system in whole your whole application. This is nothing new. There are many implementations now. I think like at XES is one of them. They use more of an event system, more and more applications. Nowadays, JavaScript frameworks are using this way of building applications. And no more blob state objects. This means no more, and this is a very important one. There is no more like states. The state is something, wait, I'll say we have a web development, sometimes a very bad habit of keeping well, very big state objects where this isn't that state, this isn't that state, this isn't that state. Well, this is fun if you have like small applications, but this doesn't work once you start scaling. So in what I'm proposing here is that every little application has its own state and is never past the state. It will always determine the state from whatever happens later on, which makes development much easier. And it's always more important to always state is always a reaction or calculated. Counts, of course, single point of failure. Well, if your mediator breaks, everything breaks. Message overload, yeah. If you start sending out too much messages, you start to lose the ability to debug, for example. So you have to really think if you want to send out this message, just think about it. But the main part is the con is it's hardly to map the flow of data. This means if as a developer sometimes it becomes hard, if, okay, this happens here, okay, I know this service will listen to this and this will do that and this will do that. And you have to like, it's harder to do the paper trail of all your events. But yeah, it's the downside on it for it. Okay, oh, almost there. Single tons, single tons. Well, single tons are super simple. It's modules again. I don't need to explain this. This is just, what does it mean? Single ton is just a data. It's like a mini database for your data, for your application. Well, it's no, it's not the way I use them. It's like a mini database for your application. I store all my data in a single ton. This means I just create this function once in my whole application and this is where I store my data. For example, user.name.blop and I have gets and sets. If you do this again, this is easy. This is more structured. You have a kind of a contract, a predefined API. It is very self-documented. And again, it's easy to test or to mock because at the top you can dependency inject or you can do whatever you want with it. Again, again, most important, pass by reference. For example, if you would be here, if you would be returning like function.user, this will be pass by reference. So if I would be, so you get function.get and return user, if I would be like altering the user object anywhere in the application that I get back from this, I would be altering the user object inside this function. So that's a big problem. But solutions for this, you have immutables. Immutables, what does it mean? It means immutables. It means that you cannot, that you can not alter the data. This is simple. These are libraries for this. What they do is they freeze your object so you're not any, if you return the object, you're not able to edit the data after once you got it back. You have a object that free switches in vanilla, but it's only shallow, it's only one level. You have libraries like immutable.js or seamless immutable, which has better vanilla support. But you need to watch out. Most of the time there's a performance hits. So you start using like immutable objects everywhere in the application, you will get problems. It's cumbersome, it's a lot of code you need to write. And most of the times you can do just a deep clone or if you feel dirty, you can do a json.parse, json.stringify, which is a very easy way to copy data without, so you're just destroying whole link to the original object. So if you have a data service, instead of return user, I would just return a clone of that and that solves the problem also without using anything immutable. Okay, factories. So we have modules, we have dependency injection, we have magic because we have a factory. What does it mean? This is mainly for UI components. Like I said, we have the dependency injection, the params at the top. You have the whatever thing you're going to do and it just going to return a object. So what you can do is create an instance, you have reusable components, you have magic. And it's also very dry. But I mainly use it for UI components. So my structure is singletons I use for data, factories I use for UI components. You can use them interchangeably, but most of the use cases are these. Most important is, so you're not using the global anywhere. So how do you help, can you create an application? An API for this application create whatever you need. How do you can you expose this data to the user? Well, you just build a facade.  For example, I have one facade function here that has the dependency injection, the services, let's say I just inject all my services here and it just return very strict play, get user, very simple stuff. Another main benefit of this is, you're not exposing your internal API to an external party. So you also have some level of security here. And because once this get minified, the only thing that will be readable will be the play, get name and get user strings for your whole application. Hide your inner workings. You don't need to do this, let's say on a whole application, you need to do this on a whole application level, but you can also do this in smaller parts, feature parts of your application. So you have one featured and then you write it and then you just wrap a facade around with a very simple API.  So give me a URL, give me a play and that's it. It gives facilitates feature components in the feature communication against security. What does it give you? Well, all these previous steps allows you to test. Most important part again with testing is the 2080 rule. This means you don't need to write like 100% coverage, except if you work for a bank or something super, super serious, this will be enough. 2080, just get the whole idea of the application, get the important parts testing because 100% does not mean working application. Try to write good, well, let's say unit tests are good indication of architecture status. This means bad code is hard to test, so there will be no tests. The more tests and more test coverage there is available, the mostly the better and modular the code is, otherwise you cannot test it in the whole. Unit tests are contracts for you, but also for the people after you and be next to you. It helps you simplify your codes. Important part and this is seen a lot is central mock data. What I mean with this is I've seen there's a lot of unit tests where developers just, they have this small part and they wanna test it and they start writing their mock data and so whatever user object there is, they write it each test, each module again and again and again. Well, this is stupid, just create like one JSON with the whole mock data in there and then reuse it in all your tests and ta-da, you have a, you have end-to-end testing, just one mock data. In the business side, they say, okay, whatever the backend data, the data changes, the structure changes, well, the only thing you have to do is update your one mock JSON with your data and then you just have to rerun the test and watch where everything breaks. Okay, add a couple, again, this helps you. Again, don't forget the end-to-end system test, nothing very special, but just one or two simple tests that just start up your application and watch that everything is running. Night watch is very fun, I think there's a presentation about it. This Drupal call, you have test frameworks, mocha, jasmine, jq, whatever you want, test runners. Doesn't matter, so that was a hard part, yay. So now the soft systems. Well, first recap, the previous system was, the structural part was just helping you create maintainable code. So what else is it than knowing your language and knowing maintainable codes? Well, it's knowing each other, but no, soft systems. Important part, everybody knows a dry principle. Well, I think it's the most overused principle I ever saw. I've seen the duplication of code is better than a wrong abstraction. And this, oh, I've seen how many times, and then they start like altering, they create one abstraction, but it does not fit this use case, but they don't want to copy it. So they start altering this abstraction, again a little bit more, or extending it, or creating, and then in the end you have this one big blob of component or module that is un-maintainable, but nobody dares to touch. And if it was just like smaller parts, maybe some duplication, it would be easier to maintain. So do not dehydrate. Sorry, do not repeat yourself. No problem. It's the principle of trying not to copy paste around, so copy-pasting is bad, but if you write the wrong abstraction, you will get code that it's a maintainable, and I cannot understand, and you have to go like five levels deep before you get to the end codes. Keep it simple. Refactor early, refactor often. Well, I think Drupal could learn from this slide a little bit, because they done a big rewrite, and like everybody noticed, that's a lot of work, that's a lot of stress. And if you can, that's not always possible, but try to do like small refactors in your application. Keep it small, keep it simple, prevents messy and maintainable code. Voice control means whoever touches or passes by the code updates it. And again, if you want to refactor, first try to write unit tests, and then refactor, not the other way around, otherwise it will not really help you with that. But important, messy or different doesn't mean needs refactor, and this is a bad habit for programmers that they enter a project, and they see coded, and they wouldn't have written it that way, and they start refactoring just because they don't like it. If it works, it works, don't touch it. If it's going to break in the future, maybe refactor it. But remember, things just need to work, and, but you need to still understand. So it's a balance, so, and that's up to you. It's very vague, I know, but the thing I've learned the most is keep it small, your refractors.  Okay, this is my favorite slide, be critical of frameworks. In JavaScript, there are a lot of frameworks. It's moving very quickly all together, and I have no idea which framework is the best, and I'm using a lot of them, but I've noticed that a lot of business solutions, a lot of applications I could have written, I didn't need a framework, and the thing was way over-engineered, and the framework just made it way worse. So, over-engineered, keep it simple, and that's a big one, and steep learning curve. So every time you're using a framework, you need to relearn it, but also every dev that comes after you, or next to you. If you just write it stupidly in small jQuery code, probably the next dev will understand your code. If you write it in a new framework, you need to educate as a developer, you need to, it costs a lot of time, because mastering a framework costs one to two years, I guess. Specific frameworks are hard. This is one more for the PMs and the business managers, but finding a specific developer for specific frameworks becomes harder than just say jQuery or vanilla, but this is where all the freelancers make their money, is because they know one framework very well, and they are asked for this. Like Drupal? Like vanilla. Yes. Shh. Drupal is not a framework. I'm always advocating for, if you can write it in vanilla, of course, in the context of using something like NPM or Node or smaller maintainable modules, it might be the better choice, and don't believe the hype, because if you're looking most of the JavaScript and mainly in think in Drupal, if you look at the amount of complexity and code you have, that you are probably here in the middle, and you're using like Angular or React or whatever flavor is next month, is built by Facebook or a mega corporation, and they have the resources, they have the documentation, and they have, for them, it's no brainer to use this, but for you, there is a very big cost, and you don't always need it. Okay. Simple one, document. I think this is hard one, but there are simple ways of two documents, just link your commits to tickets. Document every design decision. If you have like a discussion on JIRA, just say, this is the final implementation, or whatever tickets, this is what we've done, this is why. Three lines, four lines, just say why and how. Document your whole API. I know this is hard work, but just do it. The developer after you will thank you for that. Write a setup guide for new developers. How many teams I've entered that this was nonexistent, and somebody had to spend the whole day next to me, okay, now install this, yes, set this up, okay, this is Java, okay, this is the backend, just write it once and we will be done with it. Another important one, part about documentation is that you clearly explain this is how we do it here. When somebody news enters a team, they will have their standards, their way of working. This is easy communication, okay, we don't use this, we use this, this, and this. I don't care your personal flavor, this is how we do it, this is how we do it. If you want to changes, open a discussion, you're now writing it this way. This again will enhance predictability, standardization. Okay, how many of you are working at Scrum? Scrum doing stand-ups, how many like, do you like, how many of you like doing stand-ups? The mood is changing, yeah. No, I'm pretty cool. Some developers don't like doing stand-ups, stand-ups are important communicator, we are not super communicators, so just those 10 minutes, in the start of the day, just talk to each other, get out, it's okay to fail, going over a budget, it's okay, it happens. Assumations are only, we're only humans, and good communication, like you say, and this is more of a management slide, but hey, good collaboration is A plus B, good collaboration gives A. Oh, I know, I forget how to say it in English.  So, first of all, learn new language, of course, this again, use different frameworks, get out there. The most of the things I've learned about JavaScript and mainly like patterns is from doing game dev. It's a total different world, but it has its own problems, but in the end, I learned a lot about scaling and larger stuff, and just brought that back into my application and my JavaScript knowledge. Pick up some design basics, again, developers, how many developers I've met who, this button is there, okay, it works, it looks good, whatever, don't care.  So, this may not sound sexy, but the best code I've written is on a Monday morning around nine with a pot of coffee, well rested, so treat yourself right, because doing those, like that's why I don't like hackathons, doing those long nights, keeping up all night, just working, working, working.   Question, I know it's, if you have a question, there's a mic, shoot, or you all want to go home and eat, yeah. So, I do have a question. Um, do you, it sounds like you walk a lot with Angular, right, because dependency injection, yeah, that kind of stuff. I don't like it, but it's an enterprise solution, so I run into it a lot, and I picked up mainly the dependency injection from Angular, and I really like it. All right, yeah. Um, so when you were talking about the mediator pattern, it's kind of, I mean, usually it's like the document object is the mediator object, since all the events, you know, bubble up and down from them, so, what's the difference between using documents? You can use, no, you can use the document event system, I just, I prefer my own event system, that's it, that's, okay, if you want to, you can use it, but again, the thing is, the fun part about choosing, I know it's not, it's really implementing the wheel, but the fun part is, you can have like two instances of one application, which have their own instance of the mediator, so you can reuse the same event, so you don't have to be afraid of collision of events, because you inject it everywhere, the mediator, or you can start like namespacing your events with like an ID or whatever, starting the event name with your app instance ID, that's another solution you can do. Okay. And I guess, two last ones, sorry. When you also came about state and keeping the state object like small and within, you know, the object that takes, that cares about it, but then after what do you talk about single tone? Yeah. And isn't a single tone like a big state object? Yeah, yeah. My, what I meant with state is more of, the state of the application, which that's the whole state that you would know what every button, like one object knows what every state of every button would have. That's what I mean with state. Of course, when you have like a single tone with data, it also has its own state. But what I wouldn't be doing is like watching on this, like this one button that would be constantly watching on the state of the single tone. What I would be doing if like, whether there is a data update, I would just send out a mediator event says, okay, data changed there. And then whoever is listening would get the new data and update its state. So that's kind of like what React is doing, right? Yeah. Yeah, like I said, you will recognize some parts of frameworks here and there. This is just more of the basic implementation of this. All right. And that's question. So you talked about Drupal being, you know, not great on templates and that kind of stuff. So what else can we improve? Well, can you repeat the question? What else should we improve? Oh no, I like it. Drupal JavaScript side of thing. Well, Mike, well, I have more of the, say, mainly my experiences from the seven. So I know a lot of changed, but it was mainly the... Yeah, not too much, but it's still... Yeah, I like the eight much more with the whole API first stuff. This is perfect for me. So I don't have to care about just, I have the CMS, which I can give to the clients and for improving, yeah. Well, I'm just happy there's an API. Okay, yeah, so thank you. That's all I want. It was a very good API, an explosion or exposure of that API. So I'm happy. Hi. Hi. So I was kind of confused on the slides you were talking about dependency injection. List the pros of testing and one on the icons. You mentioned that dependency injection is tightly coupled and you think it's a con to have inversion of control. So I wonder if you could explain exactly why you think that dependency injection... No, no, no, this was a bad slide. Inversion of control is a good thing. It should be on the other side. Sorry. And then do you think that dependency injection is tightly coupled and is that more from the error experience with AngularJS? Yes and no. Of course, yes, I read a lot of Angular, but the tightly coupled, even when I write vanilla, I use dependency injection a lot, I can mention. What I mean with the tightly coupled, it's the tightly coupled, I mean the, I'm okay with tightly coupled being like with the data, the data sharing between parts of the application. But once you start using like dependency injection in your components, UI components, it becomes a mess. There, the tightly coupled becomes very hard. So in other words, the way you're suggesting is when you inject dependencies, don't inject, do not inject state or... I prefer to not. I prefer that everything the user sees to keep its light and have no connection, direct connection. Because dependency injection is loosely coupled. That's the point. Yeah, it's loosely coupled, but then... Because everything you pass into it, it's the caller and not the class or the method doesn't know about its dependencies. Tightly coupled was maybe a bad explicit, a bad wording for it. It was confusing to hear that. It was not tightly coupled. You know, dependency allows you to inject whatever you want and at runtime and change that. But it's a sort of better set. I don't like using dependency injection in my UI components. That will be a better... Okay, thank you. Okay. Other questions? Do you use... So you use JavaScript in Google, right? Yourself or not? Yeah. Okay, so how do you first test that the JavaScript you write works well before writing? I mean, how do you debug it, do you? Because what I do, the practice that I do, I have a note server where I write my JavaScript and I make sure it works and does what I want. And then I import it into Drupal Adder through a module or a theme or external JavaScript file. How do you normally do it? I do the same. Yeah. Okay. Anybody else has any suggestions or anything? Or is that the best practice? I don't know if it's the best practice, but it was the most practical one. So... Yeah, okay, cool. I tried to write a second... Now I'm relieved. Okay, I do that. Okay. Thanks. Okay. Okay, thank you for your attention at this late hour. Small reminder to Friday, there are sprints. Yes. You're coming to the sprints? No, sorry. I need to be home again. And then important for the front end guys, 26 and 27th of May, there is an Athens and Greece is a new front end United. Yeah, everybody wants food. So, and if you want to evaluate, that would be kind. Okay. This would be a good tool to debug an application.


Welcome to my channel and welcome to yet another video in the series of Crash Course Unit 6 English in India History Evolution and Future. In the previous video I discussed an important act that was Charter Act of 1813 which helped English as a language to flourish across the Indian subcontinent. And in this entire video lecture series I am talking about some really really important topics when it comes to Unit 6 English in India. We are talking about why did Britishers introduce English in Indian subcontinent, what was the need, what was the intention of Britishers behind introducing this new language in Indian subcontinent. We are also looking at some of the most important acts that were passed during this period which helped English language to bloom across the country. We are also looking at this important question that how did English as a language affected the Indian languages, the Indian culture and the Indian theory of knowledge. So we are going to address all these topics in detail in the video lecture series. So if you have not yet subscribed to the channel it's time to do that so that you are notified next time I upload a video on this topic. Apart from that if you have not visited my website to look at the course that we have designed exclusively for UGC net English aspirant. And this course is as per the new syllabus divided in 10 units and the detailed course syllabus, the detailed description of topics that we are including in our course is given on the website. So you can go and visit the website arpathakarva.com and check out the detailed description about our online course which comprises of PDFs, audio lectures and mock tests. So without making any further delay let's jump right into the topic and let's see what was the role of missionaries in spreading English across the Indian subcontinent. In the last video I discussed Charter Act and we saw how Charter Act helped missionaries. In this video we are going to look at the working of missionaries in more detail. Missionaries came into India after Charter Act of 1813 was passed and their main aim was to promote Christianity in India. So they introduced English language because they felt that by introducing people to English language they can prepare them for the right kind of Christianity. They would be able to understand Christianity in its full stature only when they will have enough knowledge of English literature and English language. So the role of missionaries were not only to spread English across India they wanted to introduce and convert people into new language that is English into new culture that was western and into new religion that was Christianity. And you will be surprised to know that between 1814 to 1840 between these 25 years more than 50 missionary schools and colleges were opened all across India. And one of the best example of missionary college was the Bishop College that was opened in 1818. The impact of missionaries was that when missionaries introduced English speaking schools and colleges in India people rushed to get education from these schools and colleges. There was a fantasy in people's mind that they should be able to speak fluent English. They all wanted to become baboos and memesabs who were fluent in English. Also at the same time English newspapers were introduced in India and therefore people thought that if they would be able to read and write in English then they can also get jobs in English newspapers. As far as the employment sector is concerned there were some job opportunities exclusively for the English speaking Indians and therefore the demand for English education increased. Colleges like Agra College and Delhi College all these colleges started teaching English as a subject. Also you must note the fact that while this was happening there were two groups. One was Anglicist and the other were Orientalist. Anglicist believed that English language is superior and in India education should be imparted only in English language. On the other hand we had Orientalist who believed that Indian classical languages are way superior than English. So if you look at the Anglicist you will find out that Raja Ram Mohan Roy who was a social reformer believed that English can take Indians to a next level and he believed that by introducing English to Indians Indian brains would be able to become more powerful than they are. On the other hand if you look at the Orientalist then Warren Hastings who was a British leader he was a supporter of Oriental education and he said that in colleges education should be imparted in the Indian classical languages like Persian and Sanskrit. So you can see how few Indians were supporting English and few Britishers were supporting Indian vernacular languages. So this was how the debate and discussion about whether English or whether the Indian languages should become the medium of instruction started and it continued for years and years without coming down to a conclusion. I am sure that you must be wondering that how did this debate of Anglicist and Orientalist end and you will be surprised to know that it was Lord Macaulay whose minutes on English education played a major role in ending this debate between the Anglicist and the Orientalist. We are going to discuss the role of Lord Macaulay and the role of his minutes in the next video lecture. So stay tuned to my channel if you have not yet subscribed do it right now if you have not yet followed me on the social media platform I think you should do it so that you get notification about the latest UGC net updates. Apart from that like and share this video with other net aspirants so that if anyone is confused with the new change in syllabus with the new units which have been introduced they can get a solution right on YouTube. So that's it for this video lecture we will meet soon in the next video lecture till the time we meet next happy learning keep loving literature and stay tuned to arpitakarwa.com


Nick is my 28-year-old son. He's on the autistic spectrum. He is nonverbal and he expresses himself through his art. We're in Boston with art lifting's Liz Powers, who's pioneering a new movement in the art world, combining income and intention. And you will not believe who these artists are. For the last 10 years, I've been working with individuals who are homeless and have disabilities. And they've repeatedly told me, Liz, I don't want to hand out. I want an opportunity. In 2009, I was working at Harvard and I got laid off during the recession. And it was a very difficult time not being able to find, not even to have work. So now I'm homeless and I don't have any income. How can we change the future of social enterprise? So we're creating more jobs and we're redefining what a job is. So the economy includes more people who desperately want to work. So that's what I did after graduating from Harvard, running art groups and local shelters. I was like, wait, this artwork is amazing and a lot of it is saleable. So the new idea was, well, let's create a marketplace, curate the top artwork and then sell it. My case manager hooked up a meeting with myself and Liz. She asked me if I was interested in joining art lifting. You know, you're about to be on your way to becoming a professional artist now. Selling my art, it just never occurred to me. So one brought my mail from me from the shelter and it was art lifting and it was my first check and I cried.  We define our impact in two ways. One is obviously financial, but the second is confidence gain and that piece is actually the most important to me, is seeing this domino effect of positivity on their life. But then when I actually sell something, I don't know why I'm feeling so surprised. That's the point, but I feel this overwhelming sense of gratefulness and this is really happening.


Okay. Oh, what is the value of having an online auction without the rest of the event? We are thinking that maybe a mid-year fundraising option would be a super fabulous online auction. This would be without all the other programming and a specific event time, but more of a week long auction event. Again, sometimes I feel like we as an industry overthink what is being done. And this is going to go back to something that I've always said. $50 is $50. Do you need to raise money? What does it matter if it doesn't have a large gala attached to it?   It's just new streams of revenue and this is a new stream of revenue. Think outside the box. It doesn't have to be tied to something as a capital campaign or a funding of this or that. It doesn't have to be tied to anything. It's just an additional way to raise money and people may find it interesting. It's very little effort to prop up these type of situations and what you make from it could fund so much more than you ever thought. That can grow into something even bigger.


How are you? We are almost ready. Stay like that. It's a good place. It's a good place. It's like more ancient. I can see lots of old books. Maybe we can start from you. I'm Srinichunza from Tibet. People who are helping me told me maybe you have an opportunity in Siena University. I was so interested and I went to Google. You've never heard of it? I have never heard of it. But I think books cannot be judged by the cover. Passport is issued by India. I was born in Tibet. And the city is China. It's very complicated. Some people don't. When I graduated from high school I was thinking which university I have to go if I need to choose university in India. What should I do? At that moment I met a president of one association from Italy and who helped Tibet people especially for students, for education all this stuff. So they selected some students for cultural exchange program for the first time in 2016. As soon as I finished my board exam and then I got the opportunity to come to Asia in Italy first time. What do you study here? Here I'm doing economics at Bangi and I love this course actually because in India also I choose universities in high school which is related to more commercial economics. So I have some background and also it's more or less interesting and everything is in English. So we have many classmates from different kind of countries, you know. You said me that you don't live in the city center, right? No, I don't live here. I'm living in Montecaro the one Italian family with some Tibet people. They are so kind, honestly. So it's so good. Some of friends said I is high-heeled and all this but for me I don't have complaint about the city. I really love it. When I first went to Duomo the structure of the Duomo is so, so good. I could say most of the population Siena is student and tourist. Like one time I came here after during the holiday Siena is like empty. When schools start it's a pool of students different countries where we can interact each other All the departments in our class I can say most of them from different countries where they don't speak any Italian but for me it's not a problem. I just need to go to some coffee bar I just need to go to some shoppings and I can understand, I can survive. Is there something that you found really challenging and that actually changed your way to live, your way to... Challenge that I face and that changed my way of thinking to life, all this stuff I can say the education system. When I came here I even didn't bring my laptop everybody is like okay you go through this website and you go through this Facebook page then I start to think it's a more advanced, more developed country that's why like education system the way, the city exam everything is totally different from before When first I used calculator like this and I see that other students doing without seeing the calculator so that's the difference. Luckily you found some guys who can help you with it. It's so hard but the first week international office provides some phone numbers of students who can guide us and they really always be kind and polite to give these and that but if I need to do everything for myself almost impossible I guess. I really got interested in Italy it's ultimately I think it's deeply connected with Siena now because being here for three years built inside of me something like since Siena it's like oh I got back to home if you want to take a break you can go to Campbell to sit for me it's very you know peaceful What do you think you will be in 10 years? First I prefer to stay here I would like to work in some companies related to management yes I think I can learn Italian within 10 years for sure


First of all, what causes snoring? Now snoring is officially known as obstructive sleep apnea. That sounds kind of scary, doesn't it? Well, obstructive sleep apnea is one of the things you want to avoid, particularly if you like your brain.  And when you have snoring episodes, many, many times your oxygen levels drop dramatically. And snoring is the first sign of mischief. So pay attention to your significant other and or spouse if they're waking you up saying turn over or you're snoring or your spouse literally sends you to the other room or is sleeping with a pillow over their ears. That's a sign that you need to pay attention because if you're snoring that bad, as Dr. Aiman has said on my podcast, you're actually starving your brain cells. And one of the shocking findings of snorers is that they're killing part of their brain and it looks very much like Alzheimer's disease. So please, please pay attention to snoring. So what causes snoring? Well, there's a lot of potential causes.  Now that one is actually a remarkably easy fix. The first thing I do with my patients who are snores like this is I do not let them sleep on their back. And that's one of the first tricks to use. I like my patients to sleep on their left side and I've posted another video on the benefits of left sided sleeping. You can use two large pillows to prop yourself on your side. There are pillow like devices that you can get on the internet and you just type in anti snoring pillows and you'll actually find a number of them that actually are very successful at putting you on your side.  There are dental devices that are available to pull your jaw forward. And a lot of times these work. I like to send my patients to a holistic dentist who specializes in snoring treatments. Many times ear, nose, and throat physicians, ENTs, otolaryngologists also will have specialized devices for this purpose. And finally, quite frankly, weight loss is my most effective treatment for snoring. Why weight loss? Well, it turns out that we put remarkably a lot of fat storage in our mouth, cheeks, and neck.  And invariably, when patients go on my program for another reason, say it's for the treatment of diabetes or the treatment of an autoimmune disease, treatment of arthritis, one of the side effects that the spouse notices is that their husband or wife stops snoring. Oftentimes, I have patients return from a trip to Europe for several weeks, found that they were snoring over in Europe. And when they came back, they discovered that they had gained five, seven pounds. And as soon as that trip weight fell off, the snoring disappeared. Finally, a lot of my snoring patients or their spouses or significant others notice that the snoring corresponds to when they've had either or too much to drink or too much to eat late at night. And alcohol in it of itself will change the motor tone, the muscular tone in your airways. And again, listen to your bedmate. And if your bedmate notices that this is the trend, that's an easy fix.  So those are great tricks. Snoring is a warning sign. Secondly, we know that people who have sleep apnea do not get good quality sleep and good quality sleep. It turns out has a reciprocal effect on preventing snoring. I hate to sound like a broken record, but the average adult needs somewhere between seven and eight hours of sleep every night. And a lot of that sleep needs to be deep sleep. And unfortunately, snoring really interferes with deep sleep. So just because you're getting six hours of sleep may be inadequate to get you the sleep you need and just getting more sleep many times is part of the process of preventing snoring. Now, are there other tricks we can do? Well, I've had a video showing the benefits of olive oil.  And remarkably, air moves much better across those passages. And it's a great trick to try. It often does the job. Other tricks that you can use, mouth taping has become popular.  And many people have less than adequate nasal passages.  And many times that's a effective treatment. But word of warning, make sure that you have adequate nasal passages to accomplish this. One of the easiest ways to test that is to try altered nasal breathing like in the yoga practice, where you close your mouth and close one side of your nostril and breathe in and then close the other side of your nostril to breathe out.   Finally, try out a side sleeping pillow. They're really not very expensive and always, always, always check in with your bed partner to see if any of these tricks are making a difference. And the important thing is if these tricks are not making a difference, then it's time to get a sleep study, a sleep apnea study. Because Dr. Amon and I are in complete agreement. If you have sleep apnea, that's a dangerous thing that needs to be treated. If you found this video helpful, I think you're going to love this one. All American oats are loaded with glyphosate, even the organic ones, and are also loaded with a banned herbicide that is cancer causing in humans.


This is SiliconANGLE Media's theCUBE. It's our flagship program. We go out to the events and extract the signal from the noise. I'm John Furrier with my co-host this week, Stu Miniman, our next guest, Michael Dell. Welcome back to theCUBE. Thank you. Super excited to be with you and obviously super excited about the formation of Dell technologies. In the technology business, it's just not a lot of real-time live TV coverage. And theCUBE is a non-linear TV operation. We do everything that the TV guys on cable don't do. We do longer interviews. We ask tougher questions. And for shows that have theCUBE cover it, it makes the show buzz. It creates excitement. More importantly, it creates great content. Being a leader and being right a lot means that you get to the right answer, regardless of whose idea it was at the beginning, and regardless of how many times you change your mind along the way. Great leaders change their minds when they get new information. We've been at this now for more than half a decade. It's a unique idea that John Furrier brought to our organization. It's been exciting to see the growth of theCUBE, we've taken theCUBE internationally, and we're innovating in new ways. Always trying to push the envelope back to the point about innovation and cloud is, yes, it's lower cost. It's better economically. Yes, it's simpler, but it also drives more innovation at the same time. And it's really the combination of all these factors that do the trick. Today, video is a key part to the way in which people learn, communicate, and we are focusing our company on storytelling. A good place to tell that story is on theCUBE. It's a great way to get all your messages across to a wide range audience in a very engaging, entertaining way. I just love that format. It's been an exciting journey working with theCUBE. We get to go out to so many shows, help extract the signal from the noise, interact with such a wide variety of clientele, both practitioners, thought leaders, some big name industry people, and we've helped some people raise their profiles in there, move their careers forward, and move their businesses forward.