Forem: Danny Tseng

Webs...assemble..ly

Danny Tseng — Tue, 14 Jan 2020 21:15:32 +0000

Get that play on "Avengers assemble" title?!! All jokes aside, recently while I was browsing the web for technologies and study materials regarding the front-end development, I came across this term called "WebAssembly." I remembered hearing it a while back but did not get a chance to dig into it. In this blog, I want to discuss the information I found in regards to "WebAssembly" and some of the use and functionalities that WebAssembly can be utilized.

So what is WebAssembly exactly? Here is the definition I found on webassembly.org.

"WebAssembly (abbreviated Wasm) is a binary instruction format for a stack-based virtual machine. Wasm is designed as a portable target for compilation of high-level languages like C/C++/Rust, enabling deployment on the web for client and server applications. "

Okay... So what exactly does this mean? A simple explanation is that WebAssembly essentially is a technology that can be used to run any language in or close to native speed in modern browsers. The one language that is designed to run in native speed in browsers without the help of WebAssembly is JavaScript. With WebAssembly, you can pretty much write in any programming language such as C++ for applications and WebAssembly is going to compiled it into a bytecode format that can be run in web browsers which pretty much opens up a whole new world of possibilities for writing applications that can be run in the web.

WebAssembly might seem like a technology that is used to replace JavaScript altogether but not quite. It is actually designed to work alongside JavaScript and in fact some of the modules in WebAssembly actually requires JavaScript to run.

For quite a long time that JavaScript was the only language that could be run in native performance in the browsers. Then HTML and CSS were both adapted to be in the same way as JavaScript in terms of being the web standards. On December 5th of 2019, WebAssembly has become the 4th language to run natively in the browsers which really speaks to the significance of establishing WebAssembly as one of the few web standards.

What makes WebAssembly performs in native speed in web browsers is that all the code written by the developer are compiled in WebAssembly ahead of time before they are sent to the browser. Since the code has already been parsed to a low level machine code, it is easier for the browser to just read, validate and run the code without having the browser to do the heavy-lifting of processing and running. Which is why it is sometimes faster to run WebAssembly bytecode than regular JavaScript code.

What are some of the uses for WebAssembly? The most common uses of WebAssembly are parsing and compiling applications that require strong processing and computational power such as online games with 3D graphics, videos and music editing as well as augmented reality and virtual reality applications that JavaScript just does not have the processing power to support are some of the apps that are good for WebAssembly to handle. WebAssembly provides ways to bring applications that are traditionally operated on their own domains to the web which provides incentives for developer to bring their applications to web in terms of only needing to deal with one platform and the code is easier to support and maintain.

Some high level recaps of the advantages of programming with WebAssembly:

Able to develop web applications in languages other than JavaScript.
Bringing applications that are traditionally operated on their native domains to the web.
WebAssembly runs in major browsers and platforms.
WebAssembly does not replace JavaScript and it runs alongside JavaScript.
WebAssembly is portable and efficient. Can produce modular binary code.

Here is a really helpful article explaining how to create WebAssembly instance with JavaScript. Feel free to check it out if you are interested in how the browsers work with JavaScript and WebAssembly.

Conclusion
After searching and digging around the web for information on WebAssembly, it is not hard to see the buzz around WebAssembly because of the possibilities of bringing applications to the web that are not native to the platform. Being able to develop applications with languages that are not traditionally possible for web applications can really change our perception of what web applications can be in the future. It is exciting and encouraging and I am looking forward to see what the future holds for WebAssembly.

References
https://webassembly.org/
https://developer.mozilla.org/en-US/docs/WebAssembly
https://en.wikipedia.org/wiki/WebAssembly
https://medium.com/mozilla-tech/why-webassembly-is-a-game-changer-for-the-web-and-a-source-of-pride-for-mozilla-and-firefox-dda80e4c43cb
https://hackaday.com/2019/04/04/webassembly-what-is-it-and-why-should-you-care/

Coding with User Experience Design Principles

Danny Tseng — Wed, 08 Jan 2020 00:56:40 +0000

Note: This is an older blog I wrote back in June of 2019 but didn't get a chance to publish.

I am more than halfway through my learning of becoming a software developer at Flatiron school's software engineering immersive. As I look back from the very beginning, it is quite exciting to see how much I have learned from being able to use Ruby to build a command line application to now building web application using JavaScript and Rails for front-end and back-end respectively. One thing I found quite interesting is that when I was in the early stage of designing the outlooks of the application, I would often times find myself trying to see how the application would look like in the perspective of the end user rather than the developer. I would attribute that kind of thinking to the knowledge and discipline that I have acquired from the days when I was studying User Experience design at UW.

User experience (UX) design is the process of enhancing user satisfaction with a product by improving the usability, accessibility, and desirability provided in the interaction with a product. The main focus is on the end users. How would the users interact with the application? How complex is it for the user to use each feature? Does the application function in a way that the users expect it to? These are some of the questions that the application you are trying to build should be able to answer.

Since the answer is the users, the problems you are trying to solve should center around making the experience as effective and as efficient as possible for them. I find it beneficial to step back and think about the big picture in terms of the tasks and problems that the application is aiming to solve for the users. Develop empathy for the users. What kind of challenges the users are facing and how can we make the experience better. I would consider this to be the first step of the design process in terms of being able to identify the overarching problem and coming up with ways to solve it. Being able to find and frame the problem and generate ideas and solutions is a big part of design thinking in User Experience design.

Data collection is also a big part of understanding the issues from your target audience in the early stage of design process. Due to time constraint, I wasn't able to perform this part of the design process when I was working on my web application. Ideally you would utilize some means to collect user data such as survey to gain a better understanding of the issues the users are facing in order to confirm initial concerns as well as adjust focus according to the findings.

Once you have established a solid understanding of the issues the next step will be to come up with personas and user stories. Creating personas is good way to make your target audience come to life. Make two to three personas with names, age, occupations and background and stories about them to give them a tangible feel. Their back stories should include the activities they would do normally so you will be able to design functionalities that would be able to accommodate their needs later on in the design phase. Storyboard is also a common tool to map out the activities the target users might do and the environments and circumstances they might do them in.

During the ideation stage which is also the design stage, brainstorming is a technique that is commonly used to come up with ideas and features that would help accommodate the users' needs that are discovered from the user research phase. The point is to come up with as many ideas as possible as a team so your team will be able to sift through them to find the most relevant features and functions to include in the application.

Once your team have settled on the most effective ideas and solutions, user flow diagram will help you see how the users will complete each task and the steps they will take to complete them. It is a useful diagram that your team can use as a reference to evaluate the efficiency of each task by seeing the steps it takes to complete each task and help narrowing down the most effective solutions from your brainstorming session.

Wireframe is a layout of a web page that allows the designer to see where each feature is situated on the web page as well as space allocation and prioritization of content. Using wireframe can give you a better visual representation of the application when implementing each individual page.

At this point, you should have solid foundation to start implementing the application by utilizing the information you have gathered from the user research and ideation phase of the design process to help make the user's life easier.

For the activities/tasks manager app that my partner and I have built, we were not able to use all the techniques described above due to time constraint. However, these ideas still apply when we were designing our application albeit in a less comprehensive manner. We created some users stories to gain a better understanding of our target audience. We brainstormed for ideas that would help solve the users' issues. We used simple wireframe for visual representation of how the web application would look like and just start implementing from there.

Conclusion:

I think learning the principles of User Experience design discipline really help me think in a way that is user-centric. As I start getting more experiences designing and building applications, I will be able to not only see it in the perspective of the developer but in the perspective of the end users which should be beneficial for developing applications that is helpful for the users in need.

References:

https://en.wikipedia.org/wiki/User_experience_design

https://www.interaction-design.org/literature/article/7-ux-deliverables-what-will-i-be-making-as-a-ux-designer

https://www.usability.gov/how-to-and-tools/methods/wireframing.html

A Qucik Look into JavaScript Closure

Danny Tseng — Tue, 31 Dec 2019 19:37:07 +0000

Going back to the land of wonderful JavaScript concepts, another interesting concept to discuss in this blog is the concept of "Closure" in JavaScript. It is something that we all have encountered when working with JavaScript but might not have the most solid understanding for.

Closure in simple term is the concept that within nested functions, the inner function has access to the variables and parameters of the outer function. In this case, the inner function essentially has access to the scope of the outer function. A scope pretty much means the visibilities of variables, so the variables of the outer function is visible within the inner function. When creating a function within another function, a scope chain is created. There are three scope chains that are associated with the inner function. The first one is its own scope. The second one is the scope of the outer function. And the third one is the global scope. This is basically what closure is in JavaScript.

Below is a simple demonstration of closure.

The function print is nested inside the outer function printName and when printName is invoked, print is going to get invoked which will log the name that is being passed as a parameter to the outer function to the console. The actual console log is within the inner function which means that name is visible inside the inner function thus validates the concept of closure.

It is possible for the inner function to have more than 3 scope chains. Consider the example below.

In the above code snippet, the most inner function combine can see the variables of the outer function getSentence. Furthermore combine can also see the parameters of the most outer function saySentence. In terms of scope chain, the function combine has four scope chains which are its own scope, the scope of getSentence, the scope of saySentence and then lastly the global scope.

Closure can create unexpected outcomes especially for loops. Before the introduction of the let keyword, var was used for declaring variables. Let's consider the example below.

If you just look at the function, you might expect the results that are getting printed out to be 10, 11, and 12 respectively. However, the results that are printed out are all 13. What is happening here is that the closure which is the anonymous function has access to the outer function’s variables by reference, not by value.

This is because the variable i is declared with var and thus has function scope due to hoisting. The value of i is determined when functions a, b, and c are executed. Because the loop has already run its course by that time, the value of i will be the last value when the for loop ends which is 3 since 3 is equal to the length of the array. Thus the results are being printed out as 13.

There are a couple of ways to solve this issue. One of them as mentioned briefly earlier is to use let instead of var so hoisting of variable declaration is not going to interfere with the result. Inside the for loop, just replace var with let in front of i to produce the right outcome. Another way is to use anonymous closure.

Anonymous closure is a way to create anonymous functions and execute them immediately so the code inside the functions are in a closure where the right values will be captured once these functions are executed. Below is an example of using anonymous closure to capture the i value.

The highlighted code snippet is where the anonymous closure is created. It is also called the immediately invoked function expression(IIFE).

Conclusion
Closure is the concept of creating a function within another function so the inner function gains visibility to the scope of the outer functions. There are different uses for closure and one of them is for managing privacy for variables like the use of anonymous closure. Closure is another example of important concepts that can have surprises in the world of JavaScript. Gaining better understanding of these concepts can greatly decrease the chance of producing unexpected outcomes from our code.

Resources
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Closures
https://www.w3schools.com/js/js_function_closures.asp
http://javascriptissexy.com/understand-javascript-closures-with-ease/
http://www.adequatelygood.com/JavaScript-Module-Pattern-In-Depth.html
https://en.wikipedia.org/wiki/Immediately_invoked_function_expression

Wiz of OAuth2.0

Danny Tseng — Tue, 24 Dec 2019 22:21:57 +0000

Many of us have been using different applications on a daily basis where we need to sign in or sign up whenever we need to use them. You might have the experience where the mere fact of having to register for a new account and password deters you from wanting to even use an application. I sure have many of those experiences. Having to register and manage new username and password for every new application you are using can be really inconvenient. What if there is a way for you to have your authentication on one of the applications you own to grant access to the third party application you are looking to sign up for without you having to enter new username and password. Wait you might have already seen that magic in works all pun intended. The magic of OAuth is what makes this process possible specifically OAuth2.0.

The OAuth was an authorization framework that got introduced in 2007. The main purpose was to provide an authorization mechanism for third party websites to have limited access to your private resource and information stored on your service provider without giving your credential away. The original OAuth was largely based on two existing proprietary protocols: Flickr’s authorization API and Google’s AuthSub. The general idea is that when you are trying to sign up for an application, there may be several options available for how you will sign up for your account. Some of the options may be to grant the application the access to your Google, Facebook, or Twitter account. You may choose one of these options because you won't need to enter username and password to create a new account. That's the use and purpose of OAuth.

However, OAuth required crypto-implementation which is a pain point for developers that want to implement the original OAuth. The cryptographic requirements of the protocol and the complexity of the original OAuth signatures were major implementation challenges for anyone coming from the simplicity of username and password authentication. Then came OAuth2.0 which was introduced in 2012. It is a complete rebuild from ground-up to replace OAuth therefore it is a completely new protocol that is not backward compatible with OAuth. The implementation challenges have been greatly resolved and it provides better end user experience. OAuth2.0 is an authorization framework that is widely used by major platforms such as Google and Facebook. The goals and purposes of the original OAuth are pretty much carried over to OAuth2.0.

There are four different roles defined in the workflow of the OAuth2.0 authorization process. They are resource owner, client, resource server, and authorization server. Resource owner is the entity that is capable of granting access to its private resources. This role pretty much refers to the user who owns the resources. The client is the third party application that the resource owner is trying to grant limited access to his or her protected account information. The client can be web, mobile, or desktop applications. The authorization server is responsible for authorizing the access to the client. When the authorization process completes successfully, an access token will be granted to the client. The resource server is the host of the account information for the user. It validates and authorizes the incoming requests by communicating with the authorization server.

The general workflow:

The client request authorization to access the service resources of the user.
The user authenticates and authorizes the request and the client receives the authorization grant.
The client requests for access token from the authorization server to access the protect information of the user by sending authorization grant and other authentications to the authorization server.
If the authorization grant is valid, the authorization server issues an access token to the client application.
The client application requests for access to the protected information from resource server by presenting the access token.
If the access token is valid, the resource server will grant access to the information the client is looking for.

The above workflow is for authorization code grant is for application running on web servers. Depending on the grant type the sequence of interaction may change. There are also three other grant types which are implicit, resource owner password credentials, and client credentials grant type.

Implicit Grant:
This is a simplified version of the authorization code grant type where the access token is being issued immediately without the process of having to exchange for authorization code to obtain the access token. This practice is generally not recommended because it is not as secure as having to authenticate authorization grant.

Resource Owner Password Credentials Grant:
For this particular grant type, the user's username and password are used directly by the client to request for access token from the authorization server. This grant type is only used with trusted client applications and should only be enabled if other grant types are not available.

Client Credential Grant:
This grant type is used outside the context of the user and when the client is also the resource owner. It's used by the client directly for getting access token of its own service account. This is useful when the client application wants to update or access its own information.

Conclusion:
More and more applications are adapting the use of OAuth2.0 framework as the signup mechanism for new users. Once the new users have signed up with their google or facebook account, they will be able to sign in with those accounts without having to keep track of the exact account name and password for these applications. It is a much quicker and convenient way for signing up for new applications. Sometimes new users might be turned away because they are having to input information for registering new account without having the option of choosing their google, facebook, or other applicable accounts for sign in. Having the option of choosing to signup with other existing accounts may be key in at least getting the users' feet in the door.

References:
https://www.oauth.com/oauth2-servers/differences-between-oauth-1-2/
https://en.wikipedia.org/wiki/OAuth
https://www.appknox.com/blog/how-oauth-works-how-to-ensure-a-secure-implementation
https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/
https://www.digitalocean.com/community/tutorials/an-introduction-to-oauth-2
https://oauth.net/2/

React Native Navigation - SwitchNavigator and BottomTabNavigator

Danny Tseng — Tue, 17 Dec 2019 06:52:32 +0000

React is one of my favorite JavaScript libraries to work with because of the component based nature of the language where "write once run everywhere" is the mantra that the language promotes. Same goes with React Native which is used for building in native environment such as mobile. I have worked on a project in the called rightIn. It is a mobile application that lets the user create activities in a more spontaneous manner. In this particular post, I want to talk about one of the difference that you will find when working with react and react native, "navigation" specifically the use of navigators in react native applications.

In react, react router is the standard library for determining where each click or link will take you to on the website. In react native however, it is react navigation that you will use to structure your navigation scheme for your application.

Mobile applications are usually made up of multiple screens and the transition between these screens are usually organized and managed through navigators. There are different navigators that are available for managing navigation scheme such as DrawerNavigator, StackNavigator, and BottomTabNavigator to name a few. I used two of the navigators in my own application, the SwitchNavigator and BottomTabNavigator.

To start, once you have your react native app initialized and ready to go. Install react navigation through npm install.

    npm install --save react-navigation

I created a main navigator which is called "MainNavigator.js" like component that serve as a container for holding other navigators. In terms of hierarchy, the main container will be the outer wrapper that holds other navigators inside. In my App.js file, it's going to render and turn that main navigator component.

    render() {
      return (
          <View style={styles.container}>
              {Platform.OS === 'ios' && <StatusBar barStyle="default" />}
              <Root>
                <MainNavigator screenProps={screenProps} />
              </Root>

          </View>
      )
    }

Once I have this outer wrapper created, I can go into the main navigator to build out the navigation scheme that suits my application. There are different components available to be imported from react-navigation.

    import { createAppContainer, createSwitchNavigator, createBottomTabNavigator } from 'react-navigation';

    const AppContainer = createAppContainer(AppSwitchNavigator);

One thing to note is that the createAppContainer is important because it is the actual container that holds all the navigators inside. I named the file MainNavigator.js but the actual export default is the AppContainer.

    //MainNavigator.js

    export default AppContainer;

Let's take a took at the SwitchNavigator that I placed inside the AppContainer.

A switch navigator is used for only showing one screen at a time. In this case, the welcome screen, signup screen, or login screen usually just take up the whole screen when displaying in the mobile so switch navigator is pretty useful here. Notice the object like structure within the createSwitchNavigator method, the WelcomeScreen, LoginScreen, and SignupScreen are individual component that will be displayed in the app. The folders and file structures I used can be seen in the below image.

The keys such as Welcome, Login, and Dashboard can be used for navigation purpose via the built in method as shown below.

The line highlighted in the image is a way to navigate or redirect to the specified screen which in this case is the dashboard. Dashboard is actually a navigator within the SwitchNavigator. It is possible to nest one navigator within another to create nested navigators. The one that is nested within the SwitchNavigator for me is the BottomTabNavigator.

As the name suggests, the BottomTabNavigator can be used to create tabs in the bottom of the mobile screen as shown below. Each of the tab represents home, create, notification, and profile screen. Bottom tabs are some of the common navigation that you can incorporate in your application as well.

Conclusion
React navigation is the way to create, organize, and manage navigation scheme within the react native app. In this project, I used SwitchNavigator in conjunction with BottomTabNavigator to create navigation structure within my app. There is also other navigators that are available to use for other navigation options such as StackNavigator and DrawerNavigator. I like react navigation a lot because I think it is a quite a simple way for organizing screens and navigation schemes.

References
https://facebook.github.io/react-native/docs/navigation#__docusaurus
https://reactnavigation.org/docs/en/switch-navigator.html
https://reactnavigation.org/docs/en/bottom-tab-navigator.html

A Quick Look Into JavaScript "Hoisting"

Danny Tseng — Wed, 11 Dec 2019 00:07:04 +0000

JavaScript can be full of surprises with concepts that may not be quite obvious to many of us. In a couple of my previous posts, I have discussed a couple of them such as the use of "this" keyword and the differences and uses for the regular functions and arrow functions. In this post, I am going to continue the trend of exploring in the land of JavaScript with the concept that has caught me by surprised in the past, "Hoisting." Some of the JavaScript tests I took in the past introduced me to this particular subject and the answers to those questions were a little surprising to me so I have decided to dig into the mechanism of "hoisting" in JavaScript.

Function Declaration

Let's start with the definition of "hoisting." "Hoisting" is the behavior of moving all the declarations at the top of the scope before code execution according to GeeksforGeeks. This means that the functions or variables that are declared anywhere within the scope, local or global, will be moved to the top of the scope. One of the advantages of this mechanism is to be able to use a function before it is declared.

    sayName("John"); //My name is John

    function sayName(name) {

      console.log("My name is " + name);
    }

As demonstrated in the above code snippet that the function sayName can actually be called first and then declare later and the result will a string that gets print out with the name which is passed as a parameter to the function that gets appended to the string. However, the same effect might not be ideal for variable declarations.

Function Expression

As mentioned earlier, function declarations are hoisted to the top of the scope but not function expressions. Function expressions are not hoisted to the top of the scope as demonstrated in the below code sample.

    hello(); //Uncaught TypeError: hello is not a function

    var hello = function() {
       console.log("Say hello!");
    }

In the above code snippet, the variable hello is hoisted to the top but the function is not so when attempted to invoke the function hello, a type error is returned with a message stating that hello is not a function.

"var"

   console.log(name); //undefined

   var name = "John";

The above code snippet produces undefined when executed in browser console because the variable declaration actually gets moved above the line "console.log(name)." When the line "console.log(name)" gets executed, name hasn't been initialized so by default in JavaScript for variable declared with "var", it will be initialized with "undefined." Even though both declaration and initialization are written in one line, they are actually separated where the declaration part is getting "hoisted" to the top. Thus, the result undefined displays in the console. The above code snipped can be interpreted as below.

    var name; //declaration
    console.log(name); //undefined
    name = "John"; //initialization

"let" and "const"

I have used "var" when declaring variables in above examples for demonstrating "hoisting." There are also the "let" and "const" keywords for variable declarations, which are introduced in ES6, and are the variables declared with these two keywords getting "hoisted?" I have read somewhat conflicting information with regards to the use of "let" and "const" keywords and whether or not they are getting hoisted. Some strictly say they are not "hoisted" while others claim they are but in a different way.

    console.log(myName); //Uncaught ReferenceError: Cannot access 'myName' before initialization
    let myName = "John";

The above code snippet will produce a reference error because it's attempting to use a variable before it's initialized or assigned a value. Notice it says in the error message that "myName" cannot be accessed before initialization instead of flat out saying "myName" is not defined which means that myName is declared but hasn't been initialized. Unlike "var," the variables that are declared with "let" and "const" won't be initialized to undefined so a reference error is thrown. The above case makes me think that variables that are declared with "let" or "const" do get hoisted but have different behavior from that of "var."

Conclusion

"Hoisting" is another JavaScript concept that can be quite surprising for developers that are first starting out learning the language. The order of execution is quite different from other programming languages where the order of the lines pretty much determined the execution order. Due to the nature of "hoisting" that it is encouraged to declare and initialize functions and variables before using them to avoid unexpected outcomes. There are other nuances of "hoisting" that are not mentioned in this post but are presented in the resources below so if you want to learn more about them, they are pretty good references to dive into.

Referernces
https://www.w3schools.com/js/js_hoisting.asp
https://scotch.io/tutorials/understanding-hoisting-in-javascript
https://developer.mozilla.org/en-US/docs/Glossary/Hoisting
https://www.geeksforgeeks.org/javascript-hoisting/
https://stackoverflow.com/questions/31219420/are-variables-declared-with-let-or-const-not-hoisted-in-es6

Arrow V Regular - Functions in JavaScript

Danny Tseng — Tue, 03 Dec 2019 18:22:58 +0000

JavaScript is an ever evolving programming language that newer features and functionalities are being added to the language with each new release. It is also one of the top programming languages in the world right now. In one of my previous blog posts, I discussed the use of "this" keyword in JavaScript and how the results differ depending on the contexts for which "this" is used. In this blog, I want to look into a new feature that was introduced in ES6, the arrow functions, and the differences between the regular functions and the arrow functions.

Syntax
In terms of syntax, arrow function is more compact in comparison to the regular function.

    () => {} //Arrow Function

    function test() { //Regular Function

    }

In an arrow function expression, you can even write it without parentheses.

    const test = params => { return params };

However, if there are no parameters on the left side of the arrow then parentheses or an underscore needs to be in place of the empty params. If there are more than one parameters, parentheses are also required.

Return
In a regular function declaration or expression, a return statement needs to be present if something needs to be returned by the function. In the case of an arrow function, there does not need to be a return statement for a one line function due to the nature of implicit return that arrow functions have.

   //Regular function declaration
   function test(a, b) { 
     return a + b; //a + b is returned explicitly
   }

   //Arrow function expression
   const temp = (a, b) => a + b; //a + b is returned implicitly

However, implicit returns for arrow functions only apply to one line functions. If the function is written as the one below, the result won't be returned.

    const temp = (a, b) => {
       a + b;
    }

"this" and "new"
"Arrow function expressions are ill suited as methods, and they cannot be used as constructors." is a direct quote from the MDN web doc and what it is stating is that arrow functions are not suitable to be used in objects and can't be called with the keyword "new." Arrow function does not have its own binding to "this" so when it is included in an object, it is not going to be bound to that particular object. Below is an example of an object having two methods. One is an arrow function and the other one is a regular function.

    let person = {
        name: "John",
        speak: () => {
            return "My name is " + this.name;
        },
        speaking: function() {
            return "My name is " + this.name;
        }

    }

    person.speak(); //My name is

    person.speaking(); //My name is John

If you input this into your browser console and call these two methods, you should see only one of them is going to print out the name "John." The method that prints out the right name is speaking which is a regular function which demonstrates the fact that arrow function doesn't really bind "this" thus not ideal to be used as method inside an object.

In the case of the "new" keyword, regular functions are both constructible and callable so you can use regular functions as constructor. However, arrow functions are only callable but not constructible, they can't be used as constructors.

   let test = () => {}; 

   let temp = new test(); //TypeError: test is not a constructor

Conclusion
Arrow function is one of the most popular new features introduced in ES6 with variety of use cases. Shorter syntax and implicit return are some of the strengths that arrow functions have. However, there are also some drawbacks in choosing arrow functions over the regular functions. It really just depends on the situation and the use case to determine when to and when not to use arrow functions.

References:
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions
https://scotch.io/tutorials/es6-arrow-functions-in-javascript-getting-started
https://www.w3schools.com/js/js_arrow_function.asp

Unit testing with RSpec - Model Spec

Danny Tseng — Tue, 26 Nov 2019 18:52:30 +0000

In one of my previous blog posts, I wrote about testing with RSpec and some of the testing practices and what their corresponding specs are. I focused in particular on the Request Spec which is the spec that is used for testing controller actions such as the routes and end-points. For this post I want to talk about a testing technique that is known as unit testing in Test Driven Development and the tools that you can use to perform such test.

Just a quick refresher, RSpec is a tool that can be utilized in Ruby applications to test the various aspect of said applications from model, view, to controllers individually or in conjunction. RSpec is also a Ruby gem. In order to include RSpec in your application, simply add "rspec-rails" gem in the gem file and run bundle install. After that, you will have access to RSpec and you can begin writing test suite for your application.

Unit testing is a testing technique that is used to test different parts of the application in isolation. A unit in this case is usually the smallest part of the application. In the case of the MVC design pattern, the unit testing will be applied to the M which is the model part of the application because model is usually the baseline of the application and other features and functionalities usually involves the use of models.

To begin uniting testing on the models, we can utilize the Model Spec for testing models. In the terminal, simply type the line below.

rails g rspec:model user

"Model" in this command simply indicates that this is a model spec and the word that follows is the name of the model which in this case is user. This command is going to generate a spec folder with a models folder inside it. The user spec file will be inside the models folder. Inside the model spec file for user, you will see some code inside the file such as below.

RSpec.describe User, type: :model do


end

Within the do-end block is where you will be able to add test code for context and examples to verify the different valid or invalid attributes for model creation. The "describe" keyword creates an example group that contains a collection of related tests. Another keyword "context" is pretty much the alias for "describe" where it will also create an example group, however, "context" cannot be the top-level method. It is valid to nested describe and context within each other. Just keep in mind that the most outer method cannot be "context."

When I was working on the model spec for one of my projects, I created an example group for testing validations.

RSpec.describe User, type: :model do

  context 'validation test' do

  end
end

In my user class, I have included some active record validations and one of them states first name needs to be present.

class User < ApplicationRecord
    has_secure_password
    validates :first_name, presence: true
    validates :last_name, presence: true
    validates :email, presence: true
    validates :username, uniqueness: { case_sensitive: false }, presence: true

end

To validate the presence of first name, I include a test example for that. An example in this case is the it-end block which takes a string for describing what this particular test or example does.

RSpec.describe User, type: :model do

  context 'validation test' do
    it 'ensures first name presence' do
      user = User.new(last_name: 'last', username: 'username', password: '123', email: 'sample@example.com').save
      expect(user).to eq(false)
    end
end

What the code inside the it-end block above does is to try to create an user object without a first name attribute provided. There is a .save at the end of the .new() which will return true or false if the object is valid and can be saved to the database. The expected outcome for this operation is false hence "expect(user).to eq(false)." When you run rspec in the terminal, you should see this particular test appears in green which means the outcome is as expected. If this particular test appears in red, there will be error messages appear as well so you will be able to know what exactly is wrong. One possible cause for the error is the object is created successfully which means that the first name presence is not enforced properly. This is one example of how we can utilize model spec to help us figure out if the models are implemented properly and the behaviors are as expected.

Other than testing the presence of first name, you can also repeat the same process for last name, email, or other information that you want to be present when creating objects. For testing uniqueness of the username, one can create two user objects with the same user name and test if the second user can be created properly. These are some of the things that model spec can be used for performing unit testing on different models.

Conclusion
Unit testing is an important part of Test Driven Development because it ensures the smallest testable parts of the application to be working properly. This is also an integral part for other testing techniques such as feature testing, or integration testing where the use of models and classes are needed in these tests that there may be some undesired or unexpected outcome if the smallest units of the application are not working as intended.

References:
http://softwaretestingfundamentals.com/unit-testing/
https://pragmacoders.com/blog/testing-with-rspec
https://www.youtube.com/watch?v=71eKcNxwxVY

Intro to JRuby

Danny Tseng — Wed, 20 Nov 2019 00:35:24 +0000

When I began my third module of the software engineering curriculum at the Flatiron school, we got introduced to the world of javascript and all the power this language possess to be used both as front-end and back-end language. I started wondering what's the difference between javascript and ruby which we have been using for the past two modules. As I wondered through the internet to try to look for information I am seeking, I came across this curious thing called "JRuby." Initially I thought the "J" stands for javascript, however, it turns out not to be the case. I ended up deviating from my original focus and started looking into what "JRuby" is all about.

JRuby is essentially the Ruby programming language that is implemented in Java and it runs on the Java Virtual Machine. JRuby and the normal Ruby mostly have the same syntax so we can write normal Ruby code in JRuby without issue. JRuby has built-in support for a lot of gems that are commonly used in normal Ruby such as Rails, RSpec, Rake, and RubyGems. It also embeds an FFI subsystem to allow the use of C libraries bundled as gems. In addition, JRuby allows launching the Interactive Ruby Shell (irb) as Ruby MRI does. JRuby can run the Java Library as well as the C Library which the normal Ruby uses.

There are some advantages of using JRuby over the normal Ruby and one of them is the speed of execution thanks to the better computing power of Java Virtual Machine. Threading and concurrency are also big factors that make JRuby appealing to use. In normal Ruby, threading and concurrency are not really the focus when the language was originally built.

In addition to the above limitations, Global Interpreter Lock is also a factor that is hindering the speed of execution as well as performance for normal Ruby. JRuby on the other hand has real threading and concurrency that supports parallel execution which greatly improves efficiency and performance. Multiple developers can work at the same time without jeopardizing each other's work during the development process. Therefore you can run more Ruby processes with multiple threads for each process on a single server.

How To Set Up JRuby On Your Machine for macOS

If you already have Homebrew installed on you machine, all you need to do is to type the below code in the terminal to install JRuby:

                      $ brew install jruby

Otherwise see below for instructions:

Have the latest version of Java SE installed on your machine.
Go to JRuby Downloads page(https://www.jruby.org/download) and choose the "Binary" package in either .tar.gz or .zip format.
Extract it's contents to a jruby directory under your home directory.
Put the bin directory on your $PATH. You can do this by running the below command:
```
          $ export PATH=~/jruby/bin:$PATH
```
Run :
```
          $ jruby --version 
```
in your command to see if JRuby is installed successfully

Running rake, gem, rails, and more:

          $ jruby -S gem list --local
          $ jruby -S gem install rails activerecord-jdbcmysql-adapter
          $ jruby -S rails new 
          $ cd blog
          $ jruby -S rake -T
          $ jruby -S rake db:create 
          $ jruby -S rake db:migrate

Running a Ruby Program
Below is a example of how to run a Ruby program using JRuby:

          $ jruby rails server
          $ jruby ruby_script.rb

One powerful feature of JRuby is its ability to invoke the classes of the Java Platform. To do this, one must first load JRuby's Java support, by calling "require 'java'". The following example creates a Java JFrame with a JLabel:

require 'java'

frame = javax.swing.Jframe.new
frame.getContentPan.add
javax.swing.JLabel.new "Hi!"
frame.set_visible true

Conlusion

JRuby is a Ruby programming language that is tightly integrated with Java. Thanks to this relationship, JRuby has access to the powerful and vast Java libraries that developers can utilize when building applications. The processing power is also much stronger and faster which makes it overall an appealing option to use. Although, there are also downsides to it such as more time consuming to warm up, memory intensive, and lack of C Library compatibility. These tradeoffs have to be considered when determining the best approach but the integrated support of Java definitely makes JRuby a solid option to work with.

Referrences:
https://en.wikipedia.org/wiki/JRuby
https://github.com/jruby/jruby/wiki
https://www.youtube.com/watch?v=Lja3HDcHNJA
https://en.wikipedia.org/wiki/Concurrency_(computer_science)
https://www.slideshare.net/FionaTay2/why-jruby-16743985/41-ConcurrencyJRuby_has_real_threadsMRI_Ruby
https://en.wikipedia.org/wiki/Thread_(computing)
https://www.youtube.com/watch?v=qJqC6xm-2PI
https://simple.wikipedia.org/wiki/Thread_(computer_science)

Testing with RSpec - Request Spec

Danny Tseng — Mon, 11 Nov 2019 22:38:08 +0000

When building applications with Test Driven Development(TDD) approach, it is a common practice for developers to write testing code to test different parts of the application individually such as unit test or as a whole like integration test. In the context of a Rails application with the MVC design pattern, the unit test is for testing the model(which is M in the MVC) and the integration test is for testing the combination of model, view, and controller(which is MVC in this case).

One commonly used testing tool is RSpec and it is a domain-specific language that is used to test Ruby code for Rails applications. In the case of using RSpec for writing testing specs for Rails application, the equivalent of unit test concept is the model spec and the equivalent of integration test concept is the feature spec in RSpec. There is also the controller test that involves testing the routes and end-points of the application. For the controller test which is sometimes referred to as functional test, the RSPec equivalent is the Request Spec.

Controller Spec was used to be the spec that was utilized in testing controller actions. However, since the release of RSpec 3.5, it is recommended by the developers of RSpec to use Request Spec instead because of the advantages that Request Spec has such as speed for which Request Spec is much faster than the Controller Spec.

When working with request specs, the common way is to specify one or more request and response cycles for different controller actions in order to test if the endpoints are being hit correctly as well as the response body contains correct information when returned.

To create a request spec file, you can simply type in the below command into the terminal where "activities" in the line below is the name of the controller you are testing.

    rails g rspec:request users

It is going to generate a spec folder with a requests folder inside it. The users spec file will be inside the requests folder. Inside the request spec file for users, you will see some code inside the file such as below.

    RSpec.describe "Users", type: :request do


    end

Within the do-end block is where you will be able to add test code for context and examples to verify the different controller actions. The "describe" keyword creates an example group that contains a collection of related tests.

    RSpec.describe "Users", type: :request do

      describe "GET users#index" do
        it "should get index" do
          get '/api/v1/users'
          expect(response).to have_http_status(200)
        end
      end

    end

As shown in the above code snippet, you can have "describe" within another "describe" to create nested "describe" example groups for specifying what each example group is for. Another keyword that is interchangeable with the "describe" keyword is "context." One thing to keep in mind is that "context" cannot be used as the top-level method in place of "describe" specifically for the first line of code above. The describe method takes a string as an argument and the string usually states what the particular test is for. Within the example group, there is the method, "it," which is the individual test or "example." The method "it" also takes a string as an argument which is used to describe what the particular test is for. In the above case, the context or example group is for "GET" which is the index action of the specified controller. The test or example is for testing if the endpoint can be hit and response can be returned properly with a 200 OK success status code.

To test the controller action for HTTP verb "POST," we can simply create another example group for testing the create action of the controller. Just like the example above, we can provide a route for the post action to hit along with the parameters for creating the specific object of the controller which in this case is the user. See the example below.

    describe "POST users#create" do
      it 'create user with valid attributes' do
        user_params = { user: {
          first_name: 'John',
          last_name: 'Doe',
          username: 'JDoe,
          password: '123',
          email: 'johndoe@example.com'
        }}
        post '/api/v1/users', :params => user_params.to_json, :headers => { "Content-Type": "application/json" }
        json = JSON.parse(response.body)
        expect(response).to have_http_status(201)
      end
    end

As you can see above, the use of request specs is pretty much to specify one or more request and response cycles from end to end. Below is another example of request and response cycle and this time is for the update action.

    describe 'PUT activities#update' do
    it 'should update the description' do
      activity_params = { activity: {
        name: 'Basketball',
        description: 'Basketball 3v3',
        user_id: user.id,
        latitude: 47.7170,
        longitude: -122.3015,
        address: 'b coffee'
      }}

      new_activity_params = { activity: {
        name: 'Basketball',
        description: 'Change from 3v3 to 5v5',
        user_id: user.id,
        latitude: 47.7170,
        longitude: -122.3015,
        address: 'b coffee'
      }}
      activity = Activity.create(activity_params[:activity])
      put "/api/v1/activities/#{activity.id}", :params => new_activity_params.to_json, :headers => headers
      json = JSON.parse(response.body)
      expect(json["activity"]).to include("description" => "Change from 3v3 to 5v5")
    end
  end

This particular test is for verifying if the description of the activity has been updated properly. When you make a network request through the request spec, a response will be returned. In this case, the information about the object will be stored in the response.body which can be turned into a JSON object by applying JSON.parse on it which is the equivalent of response.json() in JavaScript. To verify the value of any particular attribute, the include method is useful to see if the value of a particular attribute is as expected.

Request specs are pretty useful in testing the endpoints and different controller actions to see if the functions are working properly. It is an integral part of test driven development and is a common tool for doing functional testing. Above is just a quick look into writing request specs and how each controller action can be targeted in the different example groups and example for testing.

References:
http://rspec.info/blog/2016/07/rspec-3-5-has-been-released/#rails-support-for-rails-5
https://www.codewithjason.com/difference-integration-tests-controller-tests-rails/
https://relishapp.com/rspec/rspec-rails/v/3-9/docs/generators
https://github.com/rspec/rspec-core/blob/395866dc0df64b5719429f803e2a056275bc7bd3/features/Upgrade.md#context-is-no-longer-a-top-level-method

What is "this"? A quick look into "this" in JavaScript.

Danny Tseng — Mon, 04 Nov 2019 22:50:39 +0000

I come across the key word "this" a lot when working with JavaScript. It is a key word that is used quite often when working with JavaScript and you may have come across it yourself. It is also one of the interesting concepts in JavaScript that can often produce or yield unexpected results depending on the way it is used. Here is a quick post for identifying some of the scenarios and situations that "this" can be used and what the results may be produced from them.

Think of the keyword "this" as something that is created behind the scene when a function is created and linked to the object the function operates on. The value of "this" does not depend on the function itself but rather how the function is called. In short, the keyword "this" in JavaScript refers to the object it belongs to. Depending on the factors such as how the function is invoked and the default execution context the function is executed in, the results of the execution may vary.

I think one thing that may be confusing when discussing the use of "this" is the difference between scope and context. Scope is about the visibility of the variables while context is the object a function belongs to. It is important to differentiate the two since they are not the same and without the proper understanding of these two concepts that it may be difficult to grasp the use of the keyword "this" in JavaScript. Here is an article that explains the difference between the two.

The default context is the global context and in the case of JavaScript the window object. The code below is an example of declaring and calling function in a global context.

Normal Function Call

    function test() {
      console.log(this === window);
    }

    test(); //true

When you enter the above code in the browser console, the result should be true. Let's take a look at the same code that is called in a different way.


    function test() {
      console.log(this === window);
    }

    let x = {
      test: test
    }

    test(); //true

    x.test(); //false

Implicit Binding

The result of x.test is not true because the keyword "this" in this case is not the window but x which is the object the function or in this case method "test" belongs to. This is the used of implicit binding where you are creating a function inside an object. The second "test" in the line "test: test" is the same function that is declared at the top but it is stored inside x in order to make the connection between the object and function.

Let's look further into this example. Suppose now there is an attribute name in the object and the test function on the top has "this.name" instead of just "this" alone.


    function test() {
      console.log(this.name);
    }

    let x = {
      name: "John",
      test: test
    }

    test();

    x.test();

What would the results be? The answer for "test()" is nothing gets print out because the window object does not have a name property. As for the line "x.test()", "John" gets print out because it is one of the attributes of object x.

A little trick to determine which object the function belongs to is by looking at what is on the left side of the "." when making a call. A simple function call without "." usually means the function is linked to the default context which is the window object unless there is other bindings involved.

Built in methods like call(), apply(), and bind() are also other ways of binding function to an object. I won't get into the details of how call() and apply() work but they are basically called the "explicit binding" that you can use to bind functions to a specific object so you can call an object method with another object as argument. As for bind(), it is called "hard binding" when you bind an object to a function.

Hard Binding

    function test() {
      console.log(this.name);
    }

    let x = test.bind({name: "Doe"});

    x(); //"Doe"

When you use bind() to bind an object to a function, a new function will be created and the owner object of the new function will be the object that you bind the function with.

Here comes the little tricky part, what about the nested functions inside an object? What does the keyword "this" inside the nested functions refer to? Let's take a look at the example below.

    let x = {
      name: "John",
      test: function() {
        return function() {
          console.log(this.name)
        }
      }
    }

    x.test()();

What do you think the output of the line "x.test()()" is? This line is actually not going to print anything in the console. But wait, shouldn't the object be "x" therefore "this.name" should be "John"? This was my response when I encountered this particular example. This is the way I break this line down in a way to better understand why the answer is not "John."

For line,

    x.test()();

it can be broken down into the outer function and inner function.

    let outer = x.test //outer function
    let inner = x.test(); //inner function

The outer function belongs to the object x so if we have a console.log for printing out "this.name" in the outer function, the answer will be "John." However, in order to obtain the inner function you need to call "x.test()" because the outer function returns the inner function when invoked. Now that you have the inner function stored in a variable. The way to invoke the inner function is by making a simple function call like below.

    inner();

As such, since there is no object attached to this function call, the default context is used which is the window object. Since the window object doesn't have the "name" attribute, nothing is going to be printed out in the console but an empty string. In order to make the inner function prints out "John", bind() can be used on the inner function to achieve it.

    let x = {
      name: "John",
      test: function() {
        return function() {
          console.log(this.name)
        }
      }
    }

    let outer = x.test //outer function
    let inner = x.test(); //inner function
    inner = inner.bind(x)
    inner(); //"John"

JavaScript is a widely used language and it is imperative to have a good grasp of the concept of the keyword "this" in different contexts. There are other uses of the keyword "this" such as in the arrow function which the rules mentioned earlier don't really apply. This blog is meant to be a quick guide or refresher on the keyword "this" and some scenarios that we may encounter when working with JavaScript.

References
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/this
https://www.w3schools.com/js/js_this.asp
http://davidshariff.com/blog/what-is-the-execution-context-in-javascript/
https://blog.kevinchisholm.com/javascript/difference-between-scope-and-context/