And thank you also to Eric and Min, and who was the person from Engineers, SG? Karen. Karen, thank you for joining us and helping us out today. And TalkJS, or Virtual TalkJS. Okay, here's our timetable. We're going to have this short opening address by me, and then we will have the talks. And then, about 8.30, we will have the open mic, and it will probably deteriorate into just a chat. But we'll have an open mic session. Oh, I'll describe that later. We have a code of conduct here. Please be respectful to all the other participants and the speakers and the organisers. If you have any problems with someone not being respectful, please feel free to contact any of the organisers or the engineers, SG people in confidence. If you are interested in speaking at a future meet-up, you can come to our GitHub and SingaporeJS-talk.js. Under the issues, we have the info about the upcoming meet-ups, and that's where we arrange the speakers. So please come along to there. Should I show that? Here's the repository, SingaporeJS-talk.js, and under the issues, we have this month's issue. This is where we arrange the speakers. So please come along here and set your proposal if you're interested in speaking. Oh dear, I'm on the wrong tab. I have to find my way back. So now we're going to talk about some of the community in Singapore. So we have engineers.sg who do the recording of all the meet-ups. They also have a list of upcoming events, which is quite useful. You can find out that URL. I'm going to try again. Here's the list of events. Pretty good to see what's coming up. And also, they have a list of videos. Up here. So you can watch anything you missed, you can watch again. Then there's React knowledgeable, and they have something coming up on Friday. Of course, they do React stuff. If you want to see what's coming up for them, I recommend checking out their Twitter, because I think that is more up to date. So you can see the link for the YouTube stream on their Twitter account. Google are doing something in next Tuesday. It's going to be online. It's not going to be in their developer space. They're going to be talking about Firebase and Flutter. Then we have Talk CSS. This is in two weeks from the first of July, because they do the first Wednesday of every month. They're going to be talking about Bezier Curves. React.js is going to be coming a month from now, but you probably shouldn't go to them because it's the same day as us. So just forget about that. React.js. Never mind. And then we have a Telegram channel, if you're interested, in joining to stay up to date on our Telegram. It's called Singapore.js, as you can see. And there's also some other interesting channels you might like to join. All called DevSG. Okay, tonight we have three interesting talks for you. One about baking in Vue.js by Crystal. Then we have something about a Ruby developer who moved to JavaScript, where you run. And then we're going to have Optimizing in React from Axiota. And then after the presentations we'll have our open mic session. So if you have anything you want to share with the community, any interesting projects you found or interesting tools, something you're working on you want to share, or if you are looking for a job or if you are trying to find something for a job. And that will be in about an hour from now, hopefully. But now we're going to go straight into the talks. We're going to have about 25-minute talks. Maybe, yeah, about 25 minutes and then we'll have five minutes question and answers before we go on to the next talk. Yeah, so Crystal. Okay, I'll go ahead and share my screen. I'm disconnecting. Okay, thank you. Thank you. Can everyone see my slides? Yes, I can see. Okay, so today my presentation is about bread talk, where I'll be talking about my experience of building an intuitive baking tool using the ViewJS technology. So a little bit about me first. I'm currently an enterprise engineer at Facebook and I have about close to five years of full stack engineering experience. And for my experience with JavaScript, it started with jQuery in my first company. Then I moved on to Angular 1, ViewJS, and finally I'm doing ReactJS now in Facebook. And baking is just one of my hobbies because I really enjoy the process and also the products that I get to eat. Yeah, okay. So let's get everyone started on the same foundation with some basic knowledge of baking bread. My love for baking bread actually comes from the fact that you need very simple ingredients. So we basically only need flour, water, salt and a leavening agent. So a leavening agent can be either yeast or you can use a sourdough starter, which is made from flour and water and then fermented over time. It's basically like a cultivation of natural yeast. And next is, the second point is that you need minimal tools and this means that you don't have to clean up a lot. Technically, you can really just use your hands in a bowl and just knead your dough and just bake it on a tray in the oven. And across all the different types of bread that I've baked, I found that they have one governing method which is to first knead and make your dough. Go through one period of bulk fermentation to get the gluten structures in your bread ready. And finally, you shape your dough and after shaping, for example, shaping means like you put it into some specific shape. Like you can see on my screen here, I created this like pig shaped bread since this year was like the year of the pig. So you shape it and you go through another final proof for about any time between 30 minutes to one hour. And finally, you bake. So it's very simple five steps. But then again, you will find that there are many ways that you can complicate bread too. Firstly, you can have enriched dough which means in addition to the basic ingredients of flour, salt and water and yeast, you can add in other ingredients like eggs, milk, butter and really make your bread really complicated to get different textures. And also I've discussed about the sourdough starter. I'm trying to use a cultivated yeast instead of just active dry baker's yeast that is prepared to make the bread rise faster. And thirdly, we also can play with the hydration levels of the bread which means the percentage of water or liquids to the total amount of flour that you are using in your dough. And it really changes accordingly so you can use a mixture of milk and water or it actually changes when you actually put in sourdough starter since your sourdough starter itself is also a mixture of flour and water. And everything can get really messy in a sense because you can actually use baker's percentages where you find a percentage of ingredients in your dough and use it to create the dough and the texture that you want for your bread. So while baking a lot during this circuit breaker period, I actually came across a few problems that I wish to solve. So firstly is with the hydration levels. One problem I had is if I want a specific hydration level, say 85%, how much water should I use with regards to the flour in my dough? So it's really quite simple math where you just take, so for example you have 100 grams of flour then 85% just means that you use 85 grams of water. And because you are adding in sourdough starter that has its own hydration as well, you will also need to account for that. Then secondly is with scaling recipes. A lot of recipes that I came across online on YouTube or on blogs, they actually make very big portions. For example, they make like 200-500 gram loaves. But for myself because when you are staying at home, your family is not that big and we don't eat a lot of bread. So I really just want to make a small 300 gram loaf and it takes a lot of scaling of different ingredients while still keeping certain constants like the hydration level of the bread in order to get the size that I want. And finally with limiting ingredients, because I think a lot of people are baking during circuit breaker, right? So sometimes you have a shortage of ingredients at supermarkets. For example, you might have to substitute certain flowers or you might want to create a Hokkaido milk bread, but you don't have enough milk left and you still have the other ingredients. So how can I scale that loaf of bread down in order to use up what I already have at home? The primary preliminary solution I had was obviously to use Google Sheets. So in this case, you can see on columns C and F, I inputted the amount of ingredients that I need and I basically used the formula to help me with the scaling and the hydration of the bread. But of course, that gets a bit tedious as well and when you need to recalibrate different types of dough and so on. And then if we look back at what I talked about, the reason that I like baking bread was that it was meant to be easy, but now that we have so many factors coming in, it's no longer easy. And this is the solution that I came up with. So my idea was to build a very intuitive baking tool that most new bakers can make use of because I know that during circuit breaker or lock down quarantine around the world, a lot of people are picking up baking and they might not have a lot of ideas on many of the principles governing bread. The two main features that I realized that were critical was one is the bread hydration control. So allowing you to change the hydration of your dough easily and helping to calculate the ratio of ingredients that you need. And secondly is to scale your recipes, maybe larger or smaller. My idea was to also build a front end only single page app so that we can keep it lightweight and also means that I don't have to rent a server on say like AWS bed end server just for the calculations. And I could also leverage on GitHub pages to host my front end only single page app.  But of course there are some drawbacks. For example, you can't really create an account to save your recipes and share with your friends. So and that's why now I've decided that I would use Vue.js to make better bread. Yeah, so a little bit about Vue.js. So what I like about Vue.js is it has the HTML, JavaScript and CSS all within the same file. So we'll define like a Vue component and within that Vue component, JavaScript file, you have all your HTML, JS and CSS. And I feel that this makes it a very good candidate when you want to quickly prototype without having for you to switch between files. Like I know for other JavaScript projects you have to look through, for example, I'm changing the HTML on this file. Then I need to find a relevant JS file in another folder. And sometimes your project can get quite big with a lot of like nested folders and it becomes quite hard to find those files. The good thing about Vue.js is that it comes with a very good command line interface, which allows you to set up the project easily with just a few keystrokes. And this setup is also inclusive of like any CSS frameworks you want to use, whether you want to use any kind of linting, etc, etc. Yeah, so finally, I decided to use the Buma CSS framework and to use font awesome by compact because it supports a lot of extensive styling. It's very modular and it's very responsive and it supports responsive design, which means that my my app can be easily viewed on both mobile and web devices. So I'll go a little bit into the coding part now. So disclaimer first, I'm not like an expert in Vue.js, but for Q&A I'll try to answer as many questions as I can. Yeah. So the component structure that I've thought up is first, I will have all the state management within the Vue.js store here. And so other integral components would be first, we will have an ingredient group and this ingredient group would store multiple ingredients where these ingredients are being input by the user. So for example, one ingredient component can be the amount of flour that you want to use. The next one could be the amount of water that you want to input. Then similarly, you could have multiple ingredient groups. For this, I will talk about more about this in the demo later. And next, we would have two main tools, which are the main features of this bread calculator. So we would have like a hydration modifier that allows users to easily modify the hydration of their bread dough. And we also have a recipe scaling tool. So to start off with, I define the ingredient model using JS classes. I think it is available in ES6 and above. So I created an ingredient model which contains a key. This key is generated using a unique ID using the low dash library. And it also stores the amount. So for example, the amount of grams of this ingredient followed by the type of ingredient. The type of ingredient, for example, can be flour or can be liquids, can be your yeast or your salt. The name itself is more of like a description on the actual ingredients. So for example, if the ingredient type is flour, my name could be bread flour, cake flour or purpose flour. And finally, the group is basically to point to the group component to show what this ingredient is grouped under. And of course, this ingredient model will come with getters and setters so that we can easily modify the ingredients. For example, we want to modify the amount. Then we will use the setter to set the amount. So next is state management. I'll touch a little bit about the Vuex store here. All of our state will actually be stored in the Vuex store. So I have an ingredient object here where basically we map the key of the ingredient to the ingredient model that we created in the previous slide. And the getters is a way for you to retrieve this data conveniently. For example, I can define a get all flour and get all liquids function. The get all flowers can basically help me filter out only the flowers that are in my ingredients and similarly for liquids. So you will see that using just these two helper functions, I can now easily get the hydration of my bread, which is just amount of liquid divided by the flour. And we also have mutations. What mutation does is to mutate the state of our store. So for example, setting ingredients will allow us to append new ingredients into the ingredients list and to delete ingredients means that we will modify the state by removing ingredients from the list. And finally, we have actions as well, for example, to scale recipe. So actions will be mainly what our components will call. For example, our recipe scaler tool will be calling this action to do some calculation and update all the ingredients in our list specifically. So moving in view X has something called computed values as well, where you can define a function that does some kind of a simple calculation. And you can actually use this calculation on your HTML code to display that value without having to. So when you create this function, you have a variable that is constantly being updated when any of its dependencies changes. So then which means so say like this amount, right, is the amount of ingredient I have, for example, the amount of water. And this is the total flour amount. I can easily create the baker's percentage here, which is just sorry, which is just the amount of that ingredient divided by the total flour. And this will allow me to easily calculate the percentage of every ingredient I have in that list. And next, another thing we can leverage on is with the use of our inputs for the computed values. So if you see here, right, when I talk about this ingredient data dot amount, this is actually a computed value because it is reading it from the store. And for Vuex, we read values from the Vuex store as a computed value. But at the same time, we will also need an amount input in our data because this value can actually change. And how I handle this change is, for example, when the user sets a value here, I created this computed variable where I put in the model, which means that when the input, when the user inputs a value in the HTML, we will call this set function. And what this set function does is it will set the amount input, this variable while calling other functions here, which allows us to update the value. So this handle update will then take the amount and set it back into the store. So this is actually an action that runs back into the store. So I think for this, it is a little bit hard to understand just based on the code itself, which when later on in the demo, I will discuss it on the website itself. Okay, so now moving on to the demo. So this is the tool that I've built. So on the left side, you will see that you can start adding ingredients here into your dough. So for example, if I add a flour, then I can add all-purpose flour and I can state this to be 100 grams, for example. Then I can also go ahead and add some liquid. So this would be, and this would immediately calculate that my hydration level is 50 percent because it is 50 divided by 100. And similarly, I can add salt. So for example, two grams of salt would tell me that this is 2 percent of with relation to my flour. And similarly, if you see that I, if I add multiple flour, for example, this multiple types of flour, then the hydration level will update accordingly. Yeah, and if I were to say I want to hire a bread with a bread dough with higher hydration, I can easily change this and we will modify this value for me to make sure that it reflects how much water I will need then. And going into the next part, we can actually add Levene. So Levene is basically our mix of our sourdough starter that will go into our dough. So for Levene, this is what I would say is another ingredient group. So the main dough itself is one ingredient group, which contains a list of ingredients. And similarly, the Levene is another ingredient group. It contains its own separate list of ingredients. So if I were to add this all in. Yeah, so something like that. Then you will realize that our hydration level is actually updated because of the amount of water that we have added in the Levene plus the amount of water that is implicitly in our sourdough starter. And similarly, we can set this back to 85%. Oh, okay. I need to, I probably need to fix the decimal places, but yeah. So then it will update the amount of water that we need, for example, to 80%. And it will update this value here to reflect that. Oh, now actually you only need 78.6% of water with regards to your main dough. And for the recipe scaling, you will realize that we're able to scale by percentage. For example, if you want to make 1.5 times, then you can easily calculate and update all these values. If say you want to scale by a certain ingredient, for example, you want to scale by the amount of all-purpose flour. Say the recipe is for 150 grams, but you only have 100 grams. We can set this here. And it will make the change across to all the ingredients that you need. And similarly for the, if you want to scale by the total amount of flour that is in your main dough, in this case, which is the all-purpose and bread flour, we actually have 200 grams here. So you can update this, for example, you want to use 400 grams. You can update. So you would see that all-purpose plus bread flour is now 400 grams. And all the other values have changed as well. Yeah, so back to the slides. Yeah, so I actually put this tool up on Reddit and within an internal group within Facebook and this was the reception. So there's actually about half of the users that are returning. So I guess that's a good sign. It means that people actually want to use the tool. And some of the feedback that I've gotten across both platforms is that some of them wish to share recipes using simple things like URL parameter. So we can encode the URL parameter using the ingredients that we have and we can share that recipe with our friends. And next is they wish to modify the percentages easily. For now, the only modifiable percentage is the hydration level and you can't really modify the other percentages of ingredients. So the reason for that was I didn't really need that feature now and that's why I haven't implemented it yet. And next is for our sourdough starter. I actually made the assumption that the hydration would be 100 percent, which means one is to one ratio of flour to water. But there could be other because that one more control over this. For example, their sourdough starter could be like 110 percent hydration. Then of course, the amount of water that would be in our total bread dough would change and we need to reflect that. Finally, there were also some feedback that they want the tool to present the total dough weight so they can see whether this dough actually fits in their bread basket for baking or they want to know what is the amount of protein that is in the dough. Because I don't know some some people like to bake keto bread and stuff like that. Yeah. OK, so that's all that I have for today. So yeah, now I'll have some time for Q&A. I have a suggestion, Crystal. How about for beginners you could put in a kind of limit? So if they put some percentages really badly, it could maybe show a warning saying your bread is going to be too dry or too sloppy or it's not good. I think that was another feedback that I got, which was usually the minimum amount of hydration for bread ranges from 50 percent to maybe about 110 percent I've seen. So yeah, they were saying like some of the feedback I've gotten was to scale it down. And another thing that I've thought about was just to have a quick add button, which adds you a very basic bread recipe that you can then modify from. Yeah. There's been a couple of questions in the chat. One is, can you share the URL for your app? Let me share that. Oh, sorry. OK. Yeah. OK, so OK. OK, there's one question about frameworks. I think I would say that it really depends on what you like as well. If you want to compare, say, Angular, React and everything else for me, I would say that Vue.js itself is very similar to Angular, but it is a lot more powerful and lightweight. But then again, I've only used Angular one, so I cannot really vouch for the other versions. And for React, I would say actually the part that I like about React is that it is very object-oriented. So if you are someone who likes the object-oriented part of programming, like you want to define all your components as objects, then I would recommend yes, go for React. And for Vue.js, I would say it is very useful for quick prototyping of smaller apps. OK. For William's question on undo button, I think that's a good idea. So one way I can think of is to keep all the events within a stack and we can slowly undo it from the top of the stack. But at the same time, maybe it is not that critical a feature because I would suppose that the ingredients you add can't be that much. But maybe when you are referring to undo, you are talking more about when scaling recipes. For example, you scale it wrongly and you want to scale it back to what it was originally. Then yes, I would agree that having an undo button could be a good addition. OK. For Sylvester's question, how will you create preset percentages for the hydrogen levels? For this, I think of it more as a clam than a preset. For example, now we have 0% to 120% all. I don't think there's a, I said a max limit on that. Yeah, so it would be good if we can clamp it in a way instead of specifically saying it is preset. OK, and Alson's question. How do you find working with the Bulma framework? OK, for that, I would say that I haven't really tried a lot of CSS frameworks. So the one that I've tried a long time ago in the past was Foundation. And Foundation was really entry level CSS framework for me. For Bulma, I really like it because one of the advantages is that they have a lot of helper classes you can assign. So it makes everything really modular. You can just turn a button to a certain color or invert the colors by adding specific helpers. And some of the helpers are also common across different components. So if you want to set like the button color, you can probably use the same helper class to set on your text and your backgrounds. OK, good to know that the current version of Angular is very OOP. I haven't touched Angular for a long time. Do you think React is still object oriented now that they're using hooks? Maybe not so much anymore, but I do enjoy using the hooks a lot more than the old style. But I think in comparison, I would say that it is still more object oriented than Vue.js. OK, interesting. I also like using the hooks. They feel a bit tidier. OK, if there's no more questions, I will thank you very much, Crystal, for your presentation. OK, thank you. Oh, oh, before you go, sorry. How could people find you? How should people contact you if they want to ask you? You can find me on my GitHub, I guess, yeah. OK. So next up, we have Wei Yuan, who's going to migrate from Ruby on Rails to JavaScript. Wei Yuan, Wei Yuan, are you ready to join? Yes? Yep. OK. Let's start sharing my screen. Looks good. Yeah, looks great. Thanks very much. Backwards. All right. Shall we start? Yes, please. Go ahead. Hi guys, my name is Wei Yuan. I'm a full stack engineer at Rakuten Viki. So yeah, as you can see in the screen over here, the title of what I want to discuss today, or rather to share with you guys is migrating from a Ruby on Rails application to Node.js. Just to clarify, I think the title itself might be a bit ambiguous. I'm referring to migrating an application that we have maintained as a Rails application. For actually a huge amount of years. I'll talk about that in a bit later. And actually looking at moving that to Node. More specifically, we actually move it to this framework, which is called Next.js. The content today, because the migration itself is rather big, so I just want to focus itself on just the server side code, which is more Rails towards Node.js. And I think also to give an overview today on, you know, whether you should do a migration or maybe in some sense to also discourage you guys. If you're thinking about migration, maybe this is something that you know, maybe you shouldn't go for migration instead. Let's get started. So just as a very quick disclaimer, again, because the title itself is kind of big. I just want to mention that the idea here is that it's not a silver bullet.  The Rails application turns to the Node application. In fact, there was still a lot of work to do. I mean, we did a lot of work at the start. Right now, our entire team, in fact, I would say like 90 percent of a team is on 90, 90 percent of a team is on doing this migration currently right now. And we've done it for one year already. Again, I'll give a bit more context in a bit later. And one important thing I want to stress over here is that on neither camps, not say I support Rails more than Node. I do love JavaScript more. It's easier to do trade applications using JavaScript frameworks. But yeah, I mean, it really depends on the use case. In our company, in Viki, in our organization, we do have use cases that where the Rails stack itself suits the use case better. In our case, we actually realized that at a certain point, the Rails application or the Rails stack itself worked quite well, but we have already moved on from there. So just to I'll go a bit on that as well. Just to start off with the background before we did the entire migration. So we started our migration in 2009. So before and on 2009 itself, the site or main flagship product for Viki was run as a Ruby on Rails application. You can see over here, this is the first commit of the that were found within the repository. So 2012 at the point where we migrated, that's around, I would say, seven, close to eight years. In fact, I mentioned that we migrate over to a Node application using Next. Yes. That's also, I think some of you might know, is HAPE based on React. React came out a year after that. The first release was in 201.3. So this was something that precedes that. I think Ruby on Rails itself was also released sometime in the early 2000s. So yeah, at that part of time, it was a mature framework that a lot of organizations and teams used and to give a bit more context about the front end. So server side code, yeah, that's definitely Ruby. On the client side code, we actually started off with using a lot of coffee script. First, the idea for that or the mentality was that we wanted to have a stack where your client side code, coffee script, server side code in Ruby, both of them were very similar in syntax. So you had front end engineers or full stack engineers who can onboard the project very easily without having to contact switch so often. But as time passed, we had efforts, engineers who came in, started exploring different things, started looking at implementing React components within our application. So that caused a little bit of a mess. We had to actually look at importing this React components within our coffee script code. And of course, you can never get away from, let's say, the vanilla JavaScript that sometimes is necessary even in some sense. Sometimes within some rendered views, you need to put those scripts in for whatever reasons. So instead of jumping into the chunk of the problem or rather like today itself, I'm not going to be showing so much code. But I want to actually discuss a bit about the decision on whether you should migrate or not and how we actually land up with the decision to do the migration. So I mean, in some sense, if you are actually thinking about doing a migration, maybe this will help you push you towards or from doing a migration. OK, so as everything, you know, this is a big decision, a migration itself. We're looking at a seven to eight year old application that we are trying to move out. There's a lot of things to move out. So choosing to do migration is the solution for migration is a very big issue. You know, it's something that you don't want to take lightly. And you need to apply some proper decision making on it. And I feel that like after looking back and how we made the decision, we kind of use something along the lines of the Kipling method. Kipling method sounds like a very complicated thing, but actually it's something that most of us already know. I think if you are in college, likely your teachers would have really drew you with this methodology when you are writing like some English essay. It's basically the 5W1H, but it's also quite effective towards project management as well as decision making. So let's try to apply this methodology towards breaking down this decision in identifying our problem statement and should we go for migration? OK, so let's start off with a... OK, so just to break down into the common 5W and 1H that I want to look at. So for one of the W's, what essentially is on the focus on is what is our pain point, you know, before we talk about migration, what is the trigger that actually led us towards this path? And why should we exactly choose to do migration?  There are other ways around solving this problem. Maybe we should look at doing those things instead. So yeah, in fact, this part is about justifying. You know, if we want to do migration, the migration, why we have to do that instead of choosing some other decision? And the other three W's, in fact, that's something more within your own organization. So once you have decided the first few factors, who will do it, when you will do it, where you will do it, I guess most of us will use GitHub, Bitbucket or something along those lines. So those are something you can answer within your own organization. And the last part, the H will be the interesting part because this will be the bulk on what you'll be focusing on. In fact, what we have been focusing on over this one last year, as well as in the following year to come, you know, what we decided as our initial approach actually has sort of laid the groundwork on how this entire migration has been done from this entire year and then the next year as well. Okay, so yeah, in fact, yeah, about planning a course of action. So let's start on the first two W's first. So what were the pain points that we experienced at Vicky? And how that led us towards the solution of migration? It's starting off with the pain points. So early on, I mentioned about the initial decisions that we made. You know, we have a Rails application. We had coffee script for our client side code and that was good because it helped to reduce the contact switch. But as time passed, you know, I mentioned that we started adding React components. So now you need to bundle your transpiring of some of your React files, the JSX files together with your coffee script code. Sometimes this also requires adding no certain values within some Ruby file somewhere else. And this started causing a lot of friction somewhat here and there because sometimes people might forget to do some of these things. And then if you look at it, Ruby is very different from, definitely very different from your writing code in your React components. So what we had before, you know, that small barrier or rather a very little contact switch was actually sort of working against us because now developers already sort of isolate the client side code versus server side code. It's always two different things when they are looking at it. And that's the first point. Actually, I want to emphasize one more thing, which is that the first point itself is sort of related to a human-based problem. I think this one is kind of like my own personal opinion, which is I think for any big problems that you want to solve. Actually, you want to see first if it's related to the human because the developer happiness is so important. You know, that's something that you want to resolve if all your developers are not happy with the current decision on how on your current stack and how you are running it.  And I think one of the other things that we found out was this, you know, we have our Rails application, you know, you maintain it or rebuild on top of it for seven years. We started finding out that, you know, it wasn't the best environment for us to build a kick-ass front-end application. You know, we are talking about modern principles, like having an isomorphic application, a single-page application for optimizing performance. I mean, we did try out something along the lines of using P-Jax on some of our pages, but it wasn't scalable. You know, we could only do it on one single page. The code itself looks very messy. We couldn't move that, you know, ideology across. In fact, that was only on one single page. It wasn't cross, it wasn't rolled out across all our different views in the website. And I think one of the conscious points that we sort of came towards, realizing two words was that, if you look at the initial first two points, it's the damage that they can cause grows as the time passes. You know, if we choose not to do migration now, we do it three years later. You know, newer principles are going to come in place, newer ways of optimizing the front-end, your client-side code comes in. You know, these are things that we might not be able to do using our current framework. We did attempt using Webpack a few years before, but because of our coffee script code, we weren't able to make that transition fully. So because of difficulties like that, we decided, I mean, we tried out a few solutions over the few years, but we slowly realized that, yeah, migration seems like the only way to go. So explaining a little bit about why we end up with the decision of doing the migration. The idea is this, previously I talked about the contact switch for between the Ruby code towards the coffee script code. And we wanted to look at moving to a JavaScript application where, as I mentioned, isomorphic application, the server-side code is sort of mixed with the client-side code. There shouldn't be this huge contact switch or jump for the developer. Whenever they need to write or create some features, they shouldn't have to have this huge barrier to drum across every single time when they're building these features. And very importantly, again, optimizing the human factor. You want the developers to be happy, because if they're satisfied with the current code base that they're dealing with, definitely they'll be able to create a better product overall. And again, the counterpoint to the earlier problem phase, which is we want to be able to embrace newer technologies, newer principles, in fact, using a framework that supports, that's supported as a single-page application using Next.js, being able to incorporate principles like lazy loading to allow us to have that gigantic shift over from a legacy rules application over to something that was more reminiscent of front-end applications, performant front-end applications that you can see in today's market. And I think one of the other important points that I want to emphasize was that it wasn't just about fighting the justification, the small points or big points towards the problems that we identified. I think one of the other things is we actively experimented like years before. I mean, we had this rules application. We stick with it. We tried different, like smaller solution to fix the problems that I mentioned. And along those time, along that period, we looked at experimenting on other solutions. I think last year we shared about our effort in rewriting Soompi. We changed from a PHP application, it was a WordPress over to a single-page application created using RedRouter. And then around a year before, in fact, half a year after we did our project with Soompi, our manager came up with the idea that next year seems to be picking up traction, a lot of companies are using it. Let's try it for another small project on the side. And then the developer feedback seems to be pretty positive about writing the application using Next.JS. So this sort of helped to push the direction towards, okay, we want to do this migration. We've found a lot of success with these different frameworks. Let's try to use these frameworks to solve the problem that we see over here. And this is something I also would encourage within your own organization or within your own teams. If you can afford to experiment with smaller projects, you want to do that before you make the big decision, this huge leap to do the migration. So I hope I've sort of convinced you on why, what are our pinpoints and why we had to go with the solution of migration? I think I would just want to end that off in that sense, like at a very high level. But I want to talk about some of the interesting things that I encountered along the lines of migrating from a real application to Node. And this one is more on the backend slash DevOps portion. This is not a silver bullet. I think some of the, well, okay, I'll just jump to the solution or not solution the problems and let you guys see what it is. Okay, so first off, I just want to mention, okay, so now that we've decided on the approach to do the migration, where do you start first? Of course, you must always go back to your team, get everyone in the same room. That's what we did at the start. Try to see what's everyone's opinion on how we can do this. And the final decision that was made by our manager at the end was let's support both applications together at the same time. Instead of just doing this migration in one big leap, where you take all the product, the features within the real application over the Node application, why not support both the real application and the Node application at the same time and look at slowly moving the features across. So that in some sense, we can also seek to sort of understand with analytics whether the Node application is actually performing better versus a real application. Okay, and to do this, you can use what is called the... At the point of time where we did this, the name of, or rather the methodology itself wasn't actually known to us, but this was something that I picked up recently, which I found that actually, yeah, this was exactly what we did, which I believe this is coined by Martin Fowler, which is the strangler pattern where you're looking at in terms of doing a migration, supporting both the legacy as well as the new application. And in our case, you can see over here, the legacy application is referring to a real application. The new application itself is our Node application. So early on, we'll be looking at moving parts or small portions of the features or pages over to the new application. And over time, that will become, that amount will increase more and more. And eventually, you should get your Node application where you have taken over all the new features. And then you can look at just removing any other resources that you have put in to maintain this entire pattern. So this is a very high-level description on how our migration plan. So let's touch on some of the core details and maybe some interesting points. So just to recap a bit on the previous slide, the idea that we are going with the strangler pattern at the core itself is referring to migration by page or feature. So at the start, we look at migrating our home page first. And currently, we are looking at migrating a bunch of other pages as well. So we're looking at it moving as either a single page or a group of pages that's sort of the same feature. And actually, I want to emphasize that I wouldn't say that is a, again, no silver bullet, like if you want to migrate it in a different way. Definitely, there's definitely other approaches to this. Okay, so some of the interesting issues that I helped to resolve, in fact, what we found to be locked us early on when we did this migration between the Rails to the Node application were these few points. So first thing is that we measure that we want to support this strangler pattern. You need to have both server side servers, Rails server and your Node server to run at the same time. And they must be behind one single IP because for Viki.com, that has to be resolved to a single IP address. And you must use some form of methodology to support both servers behind this one single IP address. So that was our first problem. Second problem is about cross application issues. The way I, okay, so now that I'm saying it, it doesn't sound very complicated, but as I go deeper later, you'll see like why this is actually a larger issue. And then some workflow replacements. So in our Rails application, we had part of our workflow where we looked at using some scripts to help us push our translations to our translation platform. And you know, that was in using rig files in Rails. How do we translate that to a Node service instead? Okay, so let's try to answer the first question first. How do you support both servers from the same IP address with the same host name? Okay, so since we are looking at moving over to a Node application, I mean, immediately we could just use our Node application as a proxy as well. And for those who might not know what I meant by this, essentially what I'm hinting at is using your Node server as a reverse proxy. So what happens is that for the host name of Viki.com, you just need to make sure that it resolves the IP address fronted by your Node application. And basically what you do after that is you just need to make sure that you capture the Rails that you want to support on your Node application. And then the fallback, which is for every single Rails, push it over or proxy over to your real server. If you want to do that in Node application, so this is an example I got from the Stack Overflow solution. I mean, if you want to use it with the Express framework, it works as well. The idea is very simple. Essentially, you just want to use the HTTP library, create a request object, and then pipe the proxy your request over to your real server and basically just pipe the response from the proxy server back to your current response for your current request that you're proxying. But this one, creating your own solution itself might be a bit complicated.  Maybe, let's say, I mean, is there a library that can do something like this? If you look around, there's actually a Node module that you can use. So instead of creating the proxy code yourself, you can just use this library called Node.httpproxy. So examining this solution, it does solve the problem. But at the earlier part, when we first talked about this, I mean, it looks like a suitable solution. But looking at it from the long term, we felt that it wasn't a very good solution, even though this was something that we can couple within our Node server. But the idea is that we're coupling two different purposes together. Instead of just focusing on the one Node application request, only supposed to support the features that we have migrated onto, we have covered additional purposes on it. And this also conflicts with part of our, say, is the next JS framework where, I mean, they allow you to create that custom server.js, but there's also a preferable way where you can choose to do without that altogether. And to convince you with, like, on this coupling situation, the idea here is this, all you need is for your Node server to go down, and all your proxy requests that are currently in the air or currently in the wire, or let's say, the moment your Node server crash, your real service is sort of uncontactable as well, because your Node server is essentially your reverse proxy here. And then for those who have quoted in JavaScript, you know that for Node server, all you need is one single error for that single process application crash. So that might not be the most ideal situation. I mean, if we need to deploy a new Node application where, let's say we're experimenting on something, that might actually impact our real application in different ways that we might not expect. So looking at our original solution, we started thinking, is there a different or better way to do this? So why not instead of using your Node application as your Node server as a proxy, a reverse proxy, why not just implement your own reverse proxy on top of your two different servers that you are trying to support? So essentially, you just need to make sure that your proxy, over here I wrote that we use an NGINX proxy, but in fact, you can just use anything that you want, as long as it suits the purpose over here. So with a single host name, make sure that it resolves to the IP addresses fronted by this proxy, and then in the proxy itself, you can set in certain rules to direct to either the Node application. So the methodology for this is very simple. You just need to make sure you set the rules for this proxy passing to work, and this rules itself is essentially the same thing I mentioned earlier on, the match paths. So for every route that you migrate over to let's say Node.js, your Node.js service, you can just add those routes into your reverse proxy and indicate to them that you want these paths to actually point to your Node.js service in state of Rails. And there's two ways of doing this. You can either do it using a white list or black list. At this point of time, what I can say is that we are actually doing it more as a white list because we have only migrated a few routes over. So white list here is referring to that. We just want to white list a couple of different paths that we want to redirect to the Node application. But let's say towards the point where we have migrated 90% of all our paths over or features over to our Node application, we might actually switch that over and turn it into a black list where we can say, okay, for the remaining 10% of all the routes or paths that we have not migrated or features that we have not migrated, send them over to the Rails application instead. So this will help to make things more manageable as we do the migration. So that solves the problem about having two different applications or servers co-existing behind one single IP address. Okay, so to the second problem, or what I would say the more interesting problem that I can share, I just want to start off first by addressing the third point that I mentioned earlier on, which is for workflows. If you are looking at migrating from a Rails application to a Node application, you have rig files. You might just want to use the NPM run script instead. It's a very clear card solution. Basically, your rig files are like the scripts that you can run in your command line. NPM run scripts are essentially the same thing. Okay, so towards the, what I would say is again, something that I'm very excited to share, the interesting problem of the interesting problems that we faced when we did the migration, as well as it was kind of a big blocker that was sort of blocking us from actually doing the migration all together. And let me explain more about this. Okay, so the problem statement is essentially this. We have our original Rails application. We allow users to log in using that Rails application. And with the login action, you have your user sessions. How are you able to communicate this session over to your other Node application? How can you allow this user session to coexist within two servers at the same time? I think for some of us, the solution might be quite obvious if you are already familiar with certain load balancing concepts or supporting the user sessions across multiple regions, different classes supporting the same server, where you just need to make sure that rather one solution is actually to ensure that the session is stored on the client side using cookies. So what happens here is that you use the browsers as a common interface. The set cookie header will always be written after you do the login or if there's any changes made on any path on your Rails service. And then you can use this same cookie when you are trying to hit the same or different paths in your Node application. And because both applications are using the same host name, your browser will intuitively send this package over to both services. Okay, so for those who might not know or not even know regarding cookies, basically if you go to your, let's say if you're using Chrome or any browsers, you open your developer console, you should see under the cookies, search for the cookies menu. You should be able to find like a table where you can search for your different cookies. And what you have could be something like this, you know, you have like the name of some of the cookies, you have some values that they are storing in the browser that they can use to send if the host name matches for the current site that you're on. Okay, so that sounds like a very simple solution. So what's so complex about that? Okay, so let's try and think or rather walk towards that complicated portion I'm hinting towards. Okay, so firstly, let's try to answer the question. So in Rails, we have our cookie stores that helps you create your cookies that you can send back, cookies for the sessions that you can send to the browser. How about in node? How do you do that? I think very clear card, some of us may already know about this, which is to use libraries like a cookie session to help you create that user session. Okay, but here's where the situation spirals down to the tailspin, which is that if you look at using libraries that, for example, like cookie session, the issue is that they only sign the session value. But what was exactly the problem about that? If you look at the Rails application, in our case specifically, a Rails 4 application, the cookie session is both encrypted and signed. So you can already see from here that there's a big problem. You have a Rails application that encrypts and sign the cookie, pass it to the browser. Let's say if you use the browser and try to keep the node application, your node application, let's say if you're using something like the cookie session, they would have no idea on how to pass that cookie value because it's encrypted using some logic within the Rails application. So how exactly can you solve this problem? Can we find some other libraries to solve this problem? Turns out you can, but this was something that we actually didn't went with. So there's actually this library called Rails Session Decoder. There's actually one single maintainer for this library. And the scary part about this is that there's actually not much people maintaining it. And again, because it was only maintained by one single person, there's not much people using it. Essentially, what this would mean is that if we want to use this for a flagship product, for Viki.com, we need to actually get people to at least audit the solution and make sure it works. But if you're going to go to the distance of checking other people's code, why not we write that solution instead? And actually, that was what we went with. It's a bit of a nuclear option, but it has worked for us pretty well. So in the end, what we figured out was why don't we just go to the Rails, I mean, the Rails application itself. In fact, sorry, the Rails code itself is open source. We can actually go to GitHub and look at the code. So we took reference from both the open source library, as well as the previous page that library that what we saw. We used both as inspiration to create a library that we can maintain with our own company. And this worked out pretty well because we're able to create the equivalent encryption, decryption along with signing that we can bundle with to get an upload application. So essentially this is what we ended off in the end. It's actually very simple. If you are looking at doing something similar to this, 1200 lines, this was around two days worth of work, maybe one additional day of researching to make it work. Yeah. And before I end off, I just want to mention if you have a Rails application and you're looking at moving it over the node, one thing I'll mention is if you are on the version before Rails 4, you have three of Rails 2, what are you waiting for? You should update. There's probably a lot of security flaws there. If you are on Rails 4, you might want to look at upgrading the Rails 4.1 first. Because what happened is that before Rails 4.1, they actually used a different way of serializing the user session. It was actually not in JSON before. But approaching 4.1, they changed it to a hybrid approach. Not a hybrid approach, but it was a configuration where you can choose between the both serialization pattern and the JSON serialization. And you also choose an option called hybrid, which is essentially if you have sessions who are using the old hybrid pattern, after hitting your website for one time, the Rails 4.1 itself, if you set the option, they will convert it to the JSON serialization. And then this will allow you to be able to, let's say you can set it there for maybe three to four weeks. And once you have seen from analytics that 99% of your user sessions have been converted over the using JSON. Then from that point on, you can actually look at rolling out your node application with the encryption description logic and be able to read that JSON structure as well, that user object from the cookies. Okay, so yeah, essentially it's something like this when you're configuring in Rails. I guess other tips, we actually went a bit wild with the library that we wrote because in our company, we still had people who wrote, who are still developing in Rails. And one of our pain points was actually not being able to debug from our, rather it wasn't very easy to decrypt your user sessions when you are running in production. So we decided why not we just create something additional. Since we already have the decryption and encryption logic, we wrote it as a standard library. Let's use the NPM, create it as a NPM binary and allow anyone to just come in, install and use it for debugging both the node as well as the Rails application. Okay, so I'm reaching the end. So I guess the conclusion I have here is that I'm actually leaving you with kind of the very ambiguous state whether you should do the migration or not. I think that in the end lies with the use case in our company but I hope I've shined some light into whether you should do so as well as some of the pain points like this user session thing was bugging us at the start when we discovered it but we managed to solve it at the end. But I think it's kind of like a romantic statement that I want to state or maybe I guess I want to share is like even within this migration you want to look at making long-term solutions. But I think it's important to also be self-conscious and see that actually this thing probably won't last forever. I mean if you look at Rails application it was likely created with that mentality but in the end it had to be migrated likely you know currently what we're doing few years later there'll be a new piece of technology maybe we'll have to do a migration again. But having said that the decisions made by the earlier creators of the Rails application which did it quite well where we could make it last for 7 years you know 7 years is an incredibly long time and this is something of an inspiration that's something that we can use towards now that we're doing our migration having it survive for maybe 7 years or more in the future. Yeah so with that I've come to the end if you guys are interested in reaching out to me there's few links over here and that's it. Thanks for listening. Okay so I guess I'll take some questions. Okay so I think there's one question regarding rationale and decision to migrate do you have any thoughts on hay.com and how they went for the almost no GS route? I have not seen this before so I'm going to take a quick look at that okay let me stop sharing my screen but I'm going to take a quick look at that and see if I can answer this directly. In the meantime does anyone know when you have lots of microservices you might need to they might need to know who the user is, each service might need to know in those kind of architectures how do they how does each service find out who the user is I wonder if anyone in our community has seen that in operation. Are you afraid of something like a tracing solution? Tracing I think it's well it's more like because you have the redis sorry not the redis you had Ruby on Rails and Node and they both needed to know who the user was and I was thinking there must be lots of companies in the wild who also need to have this problem especially if they have lots of little microservices they must all of those services or many of them will want to know who the user is for access rights and I wonder how they do it and I'm not sure if maybe a company I worked from the past uses used redis to do that kind of stuff I'm not sure I might be wrong about that or maybe other people have an idea yeah so a separate authentication service so it would be a third a third part of your system that's the kind of thing I'm imagining so you have Node, Rails and then an authentication service that they both talk to that's maybe another option somebody says if you use Kubernetes you can run an authentication service as a sidecar somebody has said you can use a saga pattern with an orchestrator how are you doing on your hay.com research looking at it now probably better if I can answer this offline after looking at it okay do we have any other questions from people I like your diagram of the straggler pattern it made it very clear yeah got it from some other site yeah okay so okay if you have any more questions how should they contact you on LinkedIn that should work okay LinkedIn Wei Yuan Liu is that right yes okay thank you very much let's move on to Akshata's talk about performance in React should I are you able to see it yes looks good okay great so hey everyone thanks for sticking around for the last talk of this evening and today we'll be reacting faster by building for performance in React so firstly a bit about myself my name is Akshata I'm a full stack engineer at Vicky same company as Wei Yuan before me and before Vicky I did research at NUS for three years and a long time back I was actually an architect for buildings but then I realized that my passion was coding I went on to free code camp taught myself how to code and switched to doing software full time so performance why performance well obviously nobody likes a slow website but to make it official faster websites means better user experience better user experience means happier customers and happier customers means more money and I don't need to ask if people like money so there's an unquestionable correlation between web performance and revenue and to put that into perspective I have this great visualization from Dexsecure.com which says that a site 100k a day could potentially lose 2.5 millions in a year by just a one second delay in their page load time to re-emphasize this further Google actually has an impact calculator and this provides a direct conversion from site performance to financial impact that you might bear so now that we've established the importance of having a fast website for our page X what do we do about it well mostly nothing because most of us would be using a framework like React which is fast by default and everything in life is nice everything will be fast your app is as smooth as this Ferrari till it's not please wiki try to fix issues with the chat like time tomorrow you get this feedback from a user and this is you as the developer trying to react cards so for a flashback and a little bit more context we at wiki launched a new feature called watch party a couple of weeks back and a watch party is a shared co-fuelling experience something like YouTube live where people come together to watch kdrama in real time and share their passion connect with each other over live chat this is what it looks like on the left there's a live chat on the right and the UI is simple but there's a lot going on in terms of processing on this page so as you can see there's a video playing in a watch party there could be 800 to 1400 users all chatting concurrently sometimes the message frequency goes up to even 5 per second and in a watch party that's about an hour and a half long there may be 10,000 messages if not more the feedback that we saw previously was for the chat feature on this page so we embarked on this journey to try and optimize our watch party the first thing was figuring out the tools and the first tool is the performance tab that I'm sure all of us have seen in the Chrome Dev tools and the next one is the React developer tools which is available as a Chrome extension once you install it it adds a performance tab and a profiler tab to your Chrome Dev tools now armed with these tools we'll go out hunting what are we looking for so the first pit stop is the performance tab and you start recording your questionable activity which in my case was typing a chat message and sending it out and one thing to remember is to throttle your CPU the next slow down is usually recommended because your users might have a slower device than you do as a developer once you've recorded an activity your profile will be generated with a ton of data something like this that you see here and what do you want to look for are red areas in this profile so let's go through one of the important red areas here in the frame rate graph so what's the frame rate the frame rate is basically how many times the browser is refreshing your view per second and that happens usually 60 times so 60 FPS is the normal frame rate and in the ideal world you would keep it at 60 FPS but if you have long running JavaScript this frame rate is going to dip and when it does it's going to affect the user experience negatively Chrome DevTools is smart enough to figure out when this FPS has dipped below a certain threshold and that's when it starts to put in these red marks in your frame rate graph to show you to basically alert you that these might be areas where your performance is suffering so to give you to alarm you a bit more 60 FPS means JavaScript actually has 16.6 milliseconds to run per frame and actually there's overhead, there's browser overhead every time the frame is generated so this number in reality is probably 10 milliseconds that your JavaScript has to run now that we have an idea about this let's go explore the react part of things so in the React DevTools our first pit stop is the components tab and in the components tab there's this really cool high lighting feature that you can turn on and once you do that and go to a website that's running React when you interact with the website it's actually going to highlight all the components that are re-rendering while you interact with the website what you want to look for during this is any unnecessary re-renders so if you're interacting with a small part of the website and there's something else somewhere that's re-rendering that's maybe an area that you can look at to optimize the next tab is the profiler tab it works similar to the performance tab where you're going to record an activity and what it gives you are two graphs one of them is the flame graph where it gives you a hierarchical a hierarchical graph of all your components the length of the component is based off the duration that it took to render in a base metric and the more important thing here is the color because the color represents whether this component took a longer time to render or rendered faster than the previous render so you want your component to always render faster than the first time when it rendered so if it's green or blueish green like it's shown here we are safe but if you go to the rank chart you see that I have a component that's yellow which means that that component is actually longer to render than the previous time the rank chart is slightly different from the flame graph in the sense that it organizes your components in decreasing order of the render duration that they took so we've gone through the tools we now have our goals basically we want no reds in our performance report performance tab report and we want everything blue and green in our React profiler depth reports how do we get to that so everything is about avoiding extra work and in context of React that means avoid extra reconciliation and what's reconciliation so those of us who work in React we know that React actually generates works of a virtual DOM and what it's doing is that every time you have a component it calls the render function for that component which generates a tree it takes the older tree that it has for the component compares it to this new tree which is called Diffing and then if the component changes only then does it go in to commit that to the DOM and it does this process for all its children also it recurses on the children of this render of this changed component the takeaway from this is there are two costs to React one is rendering the other is committing is changing the DOM which React is smart about it only updates the DOM if something changes but rendering is when React goes and calls the render function for all of these changed components to try and diff out the trees and this is where we can extract extra performance optimizations when you're working with React so let's go on to the first main idea which is to co-locate state and the idea is to push down this reconciliation this comparing of trees as further down into the tree as possible to give you an example I have this I have this chat component here which was the initial right of that and if you see when I'm typing something the whole chat component is re-rendering this is because when I type something I'm updating the state for the entire chat component and React is trying to reconcile everything that exists inside it now I went ahead and refactored this to extract only the input into its own component that has its own state and now when I type only that chat input changes what does it mean in terms of performance well initially when I was it was 31.6 milliseconds to render this whole thing and then after my refactor it went down to 1.5 milliseconds as render duration that's pretty good let's explore the next peak that we find and the next peak that I had was when the chat the newly sent chat message was being inserted into all of the chat messages array that I had and I'm going to introduce my second idea here which is memoization memoization is a fancy word for caching and to look at, let's look at the React render tree again so say C1 component changes what React is going to do is it's going to go down to C2 and C3 call the render functions for those components and try to diff their trees out to see if something changed in the DOM but React also provides a component update lifecycle method and if you return false from that React knows that it doesn't need to reconcile that component and skips that part of the train so over here C2 is returning false for should component update means React will never go down to C4 and C5 to try and reconcile it C3 is saying true for should component update so it comes down to C6 and tries to reconcile the tree which is correct because there was a DOM update then C7 returns false so it escapes from reconciling there and C8 is a wasted render because even though React tried to reconcile the tree there were no DOM updates so he could have skipped that how do you do this there's something called React memo and you can wrap your component with React memo give it an optional function that takes in the previous props you can add conditional logic here to return a boolean value to tell React whether to reconcile this component or not if you don't pass in this optional function then React does a shallow compare between the props and if the props haven't changed React won't re-render or reconcile this component one thing to remember here is referential equality so if you have inline functions as props or inline objects those on every renders will be recreated means your props will always be different means this React memo won't work for components like that so the first screenshot here is when the chat messages was trying to render all the internal children underneath it and the second one is when I memoized out all the chat messages inside in terms of time taken initially it was taking 34.2 milliseconds after the refactor after memoization it took only 4.2 milliseconds as render duration let's come on to the third idea now and the third idea is virtualization which is recycling the DOM and if you guys remember I talked about the number of messages that this chat has and sometimes it goes up to more than 10,000 messages so virtualization is a method in which you don't put all of those elements into the DOM you only put those elements into the DOM that are visible to your user so you have this window and as this window goes up and down your list only those elements that are visible to the user get inserted into the DOM and the DOM recycles in a way to do this there are already packages that exist like React window or React virtualized both of them are written by the same guy who's also a core developer for React at Facebook and the gains from this is basically we had 10,000 messages but logically we were storing only 2,000 as part of history and now we could get these 2,000 DOM nodes down to 30 DOM nodes by using this virtualization method so in summary co-locate state memoize aggressively virtualization but I want to add a disclaimer here don't optimize prematurely like I've mentioned before React is a fast framework on its own so if you try to optimize prematurely you might be introducing unexpected behavior of bugs that might be difficult to track down later by other developers so it's always better to wait for a performance glitch before you start using these strategies then go back measure it use the strategy and measure it again to see what's happening in the big picture here's a list of resources if somebody wants to dig down deeper it's mostly ReactJ's performance docs and kensy.blog and thank you and I'll be happy to take any questions if there are any thank you Akshata I'm sure there will be some questions I am wondering how React window React window and React virtualized work with the height of elements do they automatically do they do it all automatically or do we need to give them some help dealing with the height of elements so if your height is fixed then it handles it okay but for my case the height wasn't so they do React virtualized which is the old one it handles it okay with autosizer and that hoc takes in your element figures out the row height for that and passes it down if your row height is dynamic you need to add extra stuff to figure that out and pass it down extra hoc but it can help with these hocs yeah because for me in my I don't have a determined row height so it has to be dependent on the content so I have to wrap each of those with that autosizer row height later and then use the React window package okay thank you should I just answer the questions yes please go ahead so the pre optimization point it didn't really happen to me but most of the blogs that I read that it was a disclaimer in everything and I guess I understand why because when you memoize something you're basically saying don't reconcile it unless the props changes so say you've memoized something and another developer comes in and doesn't realize that it's only based on the props there might be there might be issues in tracking down what's happening I guess that was the point why everywhere there was a disclaimer okay variable heights are also supported and react window yep so one of the packages that's that's the variable list height but for variable row height you still need to wrap it into an hoc I think the hoc captures the height and passes it to the library the virtualization window library it's the same the whole methodology is mentioned in their docs I think it's the same it's written by the same guy I can provide a link to the slides in the top.js issue maybe yes please yes do that and we may eventually add them to the meetup but yes the GitHub is the best place I think if people want to unmute now they're welcome to they want to ask questions I think one reason you don't want to memoize on basic reason you don't want to memoize all your components is if you're doing something like animation and the component is changing every time anyway then comparing the props is just wasting more CPU and it will slow down your animation yeah but I think there's probably lots of other reasons so we should probably give this blog post a read okay Axiota thank you very much for your presentation very interesting okay so now we can move to open announcements or we can just open up for chat if you like but if anyone wants to announce anything please unmute yourself and talk to us so this is an announcement about something you've learned recently anything you've built or jobs you want or people you're looking for yes sorry please go ahead I heard someone say something just now if you're looking for a job if you're looking to hire people you can use this at all or if you even want to promote any conference virtual conferences that you saw you thought was pretty cool I mean you can just feel free to do like unmute and chat you're all on by default muted so like please unmute I don't really have a question it's more of like advice that I'd like to ask around so I'm actually with this company for about two years now and I'm on I'm rather happy with the project that I'm on I'm quite happy with it but the problem is the project is actually using a rather old stack I'm still using AngularJS so Angular version 1 and now it's not really a good period to try to change the job just to get out on a new project I feel so like I mean and I realized that recruiter that have reached out to me they are very particular about if let's say they want a Python developer to boost up they don't care about how willing I mean to a developer perspective to be honest it felt like it is quite easy to jump from a language to a language but to the hiring site it's not really the case so like how do I just want to ask like how do I just stay at my current role but at the same time get exposure to another platform another language another framework I mean building personal project is still quite a far way from like say writing production really quote so we just wonder what are the people taught on that I'm point 2 I think a lot of other more qualified people can respond but I'm point 1 about talking to recruiters frankly recruiters just do keyword mapping so like if you can manage to talk to hiring managers or developers that are already in the company I think they are a lot more open to knowing that other developers can easily learn new concepts and not have to like match the resume work forward so it's probably like a little blockage because you're talking to recruiters who actually a lot of them don't fully comprehend what they are recruiting for I mean there are a lot of great ones but like to be honest there are a lot that think that okay X is X you know like I need to match keyword for keyword to present to my clients the perfect way that they do so personally I would try to talk to someone who is already in engineering my personal opinion thank you apart from personal projects you could try and get involved with an open source project which has a running website because then you may be moving up into a slightly more production level and then you could say on your CV help to maintain this Python based website for a year or two and you can give a link to it and show it running thank you also if you're working with a team that way you can maybe get some feedback to improve your code which you don't get working on your own on a personal project hi I have a question so I'm fairly new to programming and I'm still learning a lot like from this time I just wanted to ask like what are the expectations of junior developers like in 2020 currently this is an open mic by the way so like everybody can piece of mute and then you can like give your say if you're hired junior developers we're mentored junior developers like feel free to just mention like personally you prefer working with a developer who show this kind of traits or the kind of stuff like this is open mic open discussion it's not a Q&A we did hire an open developer a junior developer a couple of months ago and we saw a few candidates we ended up hiring a guy who had not I think he'd done one programming job he had tried a few different things he'd done a few different hobby projects and they were up on github so we could go and have a look and see the quality of his code and so yeah I think it's good to have a little portfolio of projects you've done and that way we could see that he had some experience in React and he had done some reading about this and that so yeah I guess one bit of advice would be something you do look into and learn about upload it and show it off yeah build your portfolio thank you no one else has any point to add how about Richard he had a team no I guess everyone's too shy another consideration is are you someone that's good to work with that was another thing we were looking at and that can just be a personal thing are you a culture fit for the team but in general I think it means being open to learning and to collaborating and good communication it's another important factor which is often forgotten with programming but it's pretty important maybe I can add something on to that so for me I've mentored a few juniors in the past and I feel that one trait that I really makes me enjoy mentoring them is if they have the willingness to learn and they take initiative so basically try to unblock yourself first before you proceed to approach your seniors to help with you because when you try to unblock yourself sometimes it helps to build up your debugging skills and critical thinking which I think is a really important role a really important trait in this role maybe I can add another I guess it's a little bit of a controversial point but I thought somewhat useful when someone shared this with me maybe you can search up on this thing called the Darling Cougars Curve it's actually the idea when I was introduced to this was to be self aware of where you are on the curve and I think because if you look at part of the curve it goes up to a very high peak at the start and then goes up as you start realizing there's so much more that you have to learn so it's kind of like a reflection because there's so much things to learn always be open to learn from your other colleagues and go around you Thank you Going back to the first question I did like the suggestion made in one of the talks that when you want to try out a new technology a new language you do that in a small project and then you can assess without too much risk because it's only a small thing it's a good way to learn something new we had that at my previous place we had lots of small projects coming through and each project we would decide to try out one new technology sometimes two but usually one was better and then when that project was finished and the new one was starting we would decide whether to keep that new technology or go back to what we were using Maybe speaking of my personal experience I think one of the earliest things I learned was debugging I mean related to Crystal's point I found debugging as a skill extremely extremely helpful in the beginning you learn a lot of things and then you can unblock yourself it's so important I think a problem that juniors face quite often is they want to ask Google for help but they don't know what kind of keywords to use Good point I don't know the solution to that problem Help Google Maybe when a junior asks the question the answer is maybe not to give them the answer but you just say these are the keywords you need that's all they need perhaps just to unblock them it's a nudge in the right direction When I started my programming journey what I realized is that I learned to learn a lot even when you are in what they call the tutorial in some sense you still got to figure out the problem every single step along you got to be self-sufficient to find solutions I guess that's why you are talking It's good to Google something first before bothering the seniors but sometimes it's also you don't want to waste time getting if you are really stuck then don't waste time get a little bit of help but sometimes you only need a little nudge Maybe I could share my experience my experience about one year plus back when I went from tutorial to actually starting on a job as a junior what I find from a personal experience is that first you need to be familiar with your tool so I mean the tool set in the company is very different from the tool set that you want on a personal level and sometimes you don't really have a choice so you might be fixed to a certain ID good or bad you need to know how to use it so on a junior level you will always the most convenient way of debugging is like console lock or system output or permanent row in that sense they are more useful debugging tool so you can set breakpoint etc and if you are talking about front end there are even more tools that you can use for example react you have various components add-ons results inspections cars too so you will help you be more productive if you know how to use this tool and the other thing that I noticed is that the biggest difference is really about skill so when you work you play around your own project you are always looking at about maybe 6, 20, 30 files when you move out to production you are looking at I don't know I think my current project have like 20,000 files I can't really remember how many lines of code there are but like so one thing that shocked me is that how people navigate around the is they actually just do control ship F and really just do a word search but it end up to be quite useful way of looking at our code then if you are talking about like trying to get a job I I sat on the other side of the table in terms of like helping the hiring manager what we usually try to look out for is someone who one of the question that I found quite useful is that asking them about their previous project big or small and sharing about the project to them so usually just by the person talking about project you can tell whether that person is someone who is willing to learn and someone who at that point of time he might not make the best choice and he is receptive to criticism so I think that aspect is actually quite important in a team setting so yeah just my humble opinion thank you I wanted to add on to in house point that like searching through a very very large application code base and like keyword searching I think I don't know how you learn this skill other than through work experience is knowing what to search for I think this applies not just like to a large code base but it is almost like googling to a certain extent is that no what you don't know this thing but like keyword searching I feel it does come from a bit of experience in terms of like when you want to how do you narrow down your search through a 20,000 file code base I can relate to that because I'm not working on a very large project also it's like the word is very common how would you narrow it down to a point where you know you can actually find a method or find the function or find whatever you are looking for I think this is one of the most useful skills you can have if you are going to be working on a on a team on a large on a large application otherwise you just get you just get lost because you don't even know who to ask where to where to go but about the also I wanted to think about the mentoring thing but on the other point of view is that like if you end up being a mentor I think an interesting way to look at it is that it is in your best interest for your mentee to be able to solve the problem themselves so I think people might not agree with me but I think if you go all out into trying to get them to learn how to do it themselves as opposed to just sort of oh yeah this is how you do it directly just giving it to them it might take you longer upfront but I like to assume who in 10 is that like they also don't want to hold it depend on you just decide benefit on who in 10 they also want to try to do well for themselves so if you help them if you are able as a mentor to help them to learn how to do it I feel that that's a beneficial mentor mentee relationship also yeah that's it I think I wanted to supplement just that's a great point so I just wanted to supplement frankly I think in the very beginning if you're coaching someone very junior just personal experience again it could be helpful in the beginning six months or so to actually just frankly tell them these are best practices this is this is this so they don't go through this like crazy search through the entire internet not knowing what they're looking for all that things so you share with them your knowledge already how to recognize patterns in a code base so they can find easier all that kind of things frankly I think spoon feeding in the initial few months is like super helpful if they are really really new and then following that the ability to learn I think that's something we all find very precious but actually I frankly think a bit of spoon feeding in the beginning is great I don't know if anyone disagrees that makes sense if they are very very new yeah like very very very new I think the persona I had in mind was like someone new to the team but not necessarily new to say definitely I guess what I'm getting back is like a there's like a the tutorial when it comes to working itself in the sense where that's where your man thought will help you like because from doing personal projects there wouldn't be stuff you know in like a working environment but when it comes to learning itself there shouldn't be like too much of a dependency there shouldn't be too much of a crush you should be like you know self you should be able to learn on your own struggle on your own and maybe rely on your mentor a little bit at the end that's that's what I'm getting at yeah but I mean super super junior people personally speaking like when you start out in the beginning you can spend like many hours or even half a day just figuring out something which is super basic so like there's another thing that another practice I tried to take up when I was I mean that I tried to take up was if I'm stuck on something so you agree with your mentor if I'm stuck on something for 20 minutes and then I'll approach you something like that or like any arbitrary amount of time I think singing is a good idea like you also give yourself like if I I will I will spend I will go all in like 120% of my effort to try to find the answer to this for 35 minutes cannot I think it's a good idea yeah like there's a limit because you know sometimes especially when you're new you feel very pisay to ask and actually that's terrible because that's super unproductive uh yeah I think just to add in something it kind of starts by because it depends on the team so as a team lead you want to give your junior or somebody new a small and manageable problem basically you need to scope out the learning journey for the mentee I mean if you give somebody new like hey I want you to bring up this feature that is going to save us $2 million a year sort of thing no la it's pretty much unmanageable but something small like hey can you solve this logging issue over there you know it's logging the wrong message it gives it builds up confidence and it gives him a chance to spend a bit of time getting productive and learning how to grab the code base so as a junior maybe asking the team lead for a manageable task helps a lot definitely but back to the point of being stuck um I find I think it's it's confirmed different for everyone but like for very gl people like me right I tend to I will I will forever remember like the things that I took like the very simple thing that I took four hours to solve what they want I think I'm putting my brain for life like cannot forget oh you know the exasperation is very memorable but I'm sure it's very different for other people but like sometimes I also wonder like actually if I didn't get stuck I wouldn't remember it like it won't be so memorable to me that like the next time I I don't even need to google it I know because I think I wasted four hours of my youth on this stupid like apparently very simple thing I get different for everyone yeah pain is the best lesson kind of thing true but it's a it's a balance between productivity and also learning something I just depends on how much time the project has la yeah so your time box yes I'm not sure if pain really helped me because I definitely had some things I got really stuck on and then I found the solution and then in 30 seconds I solved the problem and I forgot but the thing that told me was when it was when I met the problem many times when I met the problem three times after after three times solving the same thing then that was what made me remember it I don't know if we can engineer that situation for our juniors maybe we could set them up for failure but then with a bit of repetition they will learn that lesson and then can move on to something else sounds like artificial pain some people learn like that yeah I think don't need to engineer the pain but Eric I think you don't need to engineer the pain as long as you give them manageable tasks that are within their reach but also slightly beyond them then naturally we will all learn oh but to this point coming as the child of teachers both my parents were teachers I find that there is as the teacher there is a nuance like teachers can't grasp it and for some those in my opinion are really good teachers is that they can kind of grasp because everybody has different capabilities right to me the best teachers can kind of catch like where they are students individual threshold so it's like maybe you got like three students and then one student is like this person if they do they put in their best they can get a 95 and then you have another student who is like maybe not not as strong they are maxed out it's like about 75 like to be able to catch like where this bar is I think there is a nuance to it in terms of manageable tasks on the mentor side I think that also is a skill that you would need to hone as a senior like how to be a good senior how to be a good mentor how to be able to bring someone up right that's also a skill that you kind of have to I think it's half human half technical so like you have to be very skilled technically to be able to gauge what task is appropriate and then you also have a people side of it to like kind of get a feel for like where your mentee is uncomfortable but still okay or where like they are going to break down because I don't know yeah so I think actually when you bring this up this is actually interesting as in like both sides have skills to hone it's not like a one sided thing definitely so in that case is it concert like a good initiative or it's kind of cocky in the sense that you go out to your mentor and you tell him like oh or her like this is how I learn you know like I some people like you know you say some people need a little bit of nudge some people need a bit more feeling at the start is it kind of like is it a good initiative or is it more like you know it's kind of presumptuous to like assume the team with your mentor will just adjust his piece of learning I don't think it's cocky at all I think communication is a very very critical part of the relationship and I guess of course there's the how you phrase the request or whatever but I think it's a very I think it's very good to be open and because first of all you need to be aware of yourself like you need to know you first have to have this internal combination and like a sense not yourself I do better when faced with ex or like certain styles only so after you know this then to be able to communicate this to your senior to your manager to whoever I think that that is something that we don't see a lot but it actually helps because at least in my opinion I would appreciate it if someone told me outright direct it's like I work better this way this is the style that suits me best that I would be my most productive that I would be able to move faster when faced with this particular communication style for example or like if I'm when I'm stressed I kind of behave this kind of thing if you are able to articulate it clearly but not everybody can some people don't even know that they are very stressed but they don't know I'm not stressed at all maybe it's a bit tricky but what you say I think for me I feel it's why I don't know what everyone else feels because to me it's communication I don't know what it depends on the tone though yeah again I say I find you have to phrase it I think you can be direct but respectful at the same time basically the idea is propose don't impose so you don't impose your own learning style because you think this is the best for me you really propose and say do it experimentally by experience I feel like I learn a bit better like this and then propose the advantage as to why you say I think this is actually maybe something I really don't know so if you give me a bit of time give me a bit of baseline for example then I'll be able to be a lot more productive yeah and then you see whether they agree correct how mean raise it back to more about inquire this is the way that I learn best so you are asking is it possible for us to do it this way can we explore just for a while you are coming from a place of inquiry proposal I must you will follow me throw your weight around I think most people would be open to it I feel like if someone came up to me and said they are not they are not coming in and saying that imposing their will on other people rather they are just sharing that this is how I would be advantageous for me so if it's okay can we do this I think most people would be receptive I believe I believe the tone must be the most efficient the best path the best way around not because of you yeah it cannot be like a very self-serving if it's a very amicable environment everyone is like oh you teach me well I learn well then everyone benefits it must form that kind of thought I feel that if you can phrase it that is for the betterment of the team what you are trying to achieve I think that will go down that will go down fairly okay don't forget it helps the mentor as well because the mentor is also trying to think about how to get you on board as quick as possible thank you everybody by the way if you are not already there is a junior deaf where they have discussions about these kind of things too are we coming in are you in junior deaf I don't think I am ready to apply it no it's not applied junior deaf is just another meetup where basic people starting out can get together and share common things the thing you said about how can you manage your relationship with your own mentor with your team what kind of things is important for beginners I think there will be a lot of very interesting content for you it's literally junior deaf yeah we should put that on the slides good point Min I am going to go now thanks everybody for coming and for everyone who helped to organise and join in the chat see you all next time bye bye bye wait bye I guess a lot of people are still on bye