Forem: Allen Shin

Angular vs. React

Allen Shin — Sat, 20 Feb 2021 00:39:45 +0000

I recently had the chance to interview for a company called Flywheel.io, which is revolutionizing the way that medical technology is used to process medical images captured from things like CT scans. Along with development of machine learning data pipelines, the platform also includes different annotations you can apply to the medical scans, which would help researchers and medical experts to present findings in much clearer ways. As I started interviewing for the role, I realized that the stack that they were using to build all these features was actually Angular. As someone that has found a home in React, I've always heard of Angular, but I never found the need to learn about it, since I was already busy building things in React. There are definitely a lot of key differences, some of which I wanted to share here as major points to consider when determing what these frameworks offer.

Modular Programming

If you're someone that is familiar with React, you are familiar with the component. This component, which is a single Javascript file, with multiple portions, handles everything you need for configuring the HTML being displayed, getting the data for the component through fetch requests, setting up lifecycle methods with various functions for usage in the component, and importing other libraries for use. In Angular, all of these vital actions are performed by different files. This separation of concerns is called modular programming.

A good analogy for modular programming would be the way DSLR cameras are sold. The cameras are designed so that each part of the camera has it's own function, and is essentially many different parts, which can be put together. This is in contrast to something like a digital camera that comes as one unit. Just like with DSLR cameras, Angular has separated concerns for each part of an app's activities. Modules handle importing major libraries, services handle HTTP requests, templates handle HTML layout, and components (a separate file) hold component logic and functionality. Each of these parts that you have to build out in separate files in your Angular project.

There are some major advantages this separation of concerns can provide. The first is reusability. Since each functionality is divided into multiple components, you can easily swap out parts based on how you want to customize a particular component, and reuse files(f.e. a service that makes an API call) that can serve a similar purpose in other components. Second thing is the organization. Bugs are much easier to find when the problem you're looking for has categories and labels to indicate different concerns in your project. If you've got a problem making an API call, this would be a problem in your service file, and if you've got a display issue, the bug would probably exist in one of your template files.

Templates

Another major difference in Angular is in how your HTML is displayed. Like I just mentioned, this is handled your template files. This is actually a separate HTML file in each of your component folders, so you have on template for each component. This file is in contrast to what what the return call does for the React component. A major part of Angular is learning how this display file is communicating with the separate component logic file to configure the component's behavior.

Besides the file structure, what are the actual options for manipulating the DOM? In React's focus on component structure, you can give properties to components, which will then be passed down as props. In Angular, you get a deeper system of DOM manipulation, which allows you to assign custom Angular attributes and functions to anything on the DOM, including HTML elements themselves.

One major part of this is a system called directives. I've never heard this term before, but that's because it's something specific to Angular and a core part it works. Simply, a directive is a function that executes whenever the Angular compiler finds it in the DOM. It's not just a function that exists in relation to the DOM, but is on the DOM itself, which in this case is the template file. This configuration allows you to place these functions directly onto HTML elements themselves, and even receive attributes related to the HTML element itself. Angular comes with a whole box of different kinds of directives, which are Angular specific functions for manipulating the DOM.

Including directives, Angular has syntax you need to know for manipulating your template. Here's a list of some of the major tools:

-{{ }} for interpolation. -[] for property binding. -() for event binding. -# for variable declaration. -* for structural directives.

To understand template manipulation in Angular, here's an example of each tool we just listed.

Interpolation:

<img src="{{itemImageUrl}}">

Here's an example of an interpolation where now the variable itemImageUrl is now available in the component logic that you can manipulate with the functions available there.

Property binding:

<img [src]="itemImageUrl">

Here's property binding. Actually, this statement and the interpolation example do the exactly same thing. The only difference is that for property binding, you place the brackets on the property, and the string is then treated as a variable for the component. What this is actually doing behind the scenes, is the brackets are actually creating a directive, which is a function. In this case that directive is passed in the argument "itemImageUrl", which sets it as a variable.

Event binding

<button (click)="Delete()">Delete</button>

Here's a button with simple event binding. You'll notice that the first property click is descriptive of a type of event, which in this case is when this particular button is clicked. Then you have the event that is associated with the action, defined in the component logic. Standard event binding, with slightly different syntax and event names.

Variable declaration

<input type="text" #name>
{{name.type}}

This variable declaration which is written using #name points to the HTML input element properties themselves, and allows us to use those properties elsewhere in our template. This was just one example in reference to HTML elements, but per the documentation, you can actually declare variables on templates, components, and even directives.

Structural Directives

//ngIf
<div *ngIf="data.attributes.length > 0">
  <h2>Display the data> 
</div>

//ngFor
<div *ngFor="let item of list">
  <p>{{item.name}}</p>
  <p>{{item.count}}</p>
  <p>{{item.price}}</p>
</div>

//ngSwitch
<div [ngSwitch]="itemCount">
  <p *ngSwitchWhen="0">You have no items.</p>
  <p *ngSwitchWhen="1">You have 1 item</p>
  <p *ngSwitchWhen="2">You have 2 items</p> 
</div>

What is a structural directive? As we mentioned before, a directive is simply a function that returns a value when it's found on the DOM. A structural directive then, is a function that provides a value that returns a 'structural' element or directly manipulates the DOM. This is in contrast to an attribute directive, which only returns values that concern data outside the DOM.

In the above example code, the ngSwitch statement does not have the same syntax as the ngFor statement. The reason for this is because, the are different kinds of directives. The '*' is only for ngFor, which is an example of a structural directive, while the ngSwitch, which is an attribute directive, is put into curly brackets. These two directives, with components themselves, are the 3 main kinds of directives in Angular. Given the definition of directive is simply a function which returns a value, you can actually create your own custom directives as well.

Decorators

This is actually a small difference, but is relevant in looking at the way modular programming style is configured in Angular. This is a basic decorator, which is a function that sits at the top of your component logic.

@Component({
  selector: 'app-todos',
  templateUrl: './todos.component.html',
  styleUrls: ['./todos.component.css']
})

Like we mentioned before, components are directives, and @Component represents that directive. We imported this directive from Angular's library, and is taking multiple arguments from an object. Selector allows you to customize the name of your component, templateUrl allows you to pick your template file, and styleUrls allows you to select your stylesheet.

This is a good microcosm of what Angular does. This is merely on the level of the component, but in other Angular files like module folders, you'll notice this similar pattern. Since you are creating a bunch of interchangeable parts, you are selecting which parts you want to select at multiple levels to build the application. At the component level, you import an Angular component directive and you feed it custom options. The same pattern of assembling from multiple constructed/imported options is used for modules, services, and other Angular functions.

A note on comparison to React

The pros for this kind of modular programming seems to be that there is definitely much better design architecture and scalability, with the downsides that people usually mention being that Angular is difficult to grap, since you have to learn that architecture. Based on this typical analysis of Angular, it seems to me then that everyone should just invest time in learning it and gain the better architectural foundation that Angular would provide. But why does most of the industry then use React?

I think the thing that personally bothers me as a coder is that now I have to have so many more files open to just look at one component. In React, I would be able to open files for everything regarding multiple components to look at a larger scope of code, but now I need to have two files open just to look at the component logic and display.

On the same point, but in a more general sense, it seems that the reason for a preference for React might be that it's file structure is also emphasizing a different focus, which is the single component and its state. While Angular might be focusing on scalability, the way that React has a focus on the single components and their hierarchy, seems to be placing a greater emphasis at the component level and their display.

Google maps on React

Allen Shin — Sun, 04 Oct 2020 00:10:40 +0000

This week I wanted to add a page to my grocery store application where you could show the location of the store using google maps. I tried using the Google maps Javascript API documentation, which asks you to load a script tag with the API url and key, but that led to some CORS issues for me. Based on some articles that I read, it had something to do with the issue of not being able to run the script from a front end application. So, I ended up using a library called Google Maps React which allows you to hook up the Google Maps API directly to your components.

Getting the API Key

You still need access to an API key in order for you to gain access to this library so you'll want to head over to the Google's developer console in order to sign up for an account and get the API key.

After you're connected, you will want to enable certain API's that you want to use, and for my own purposes, I enabled the Maps Javascript API and the Geocoding API. The first is for the actual rendering of the map, and the second is for converting addresses into coordinates.

Lastly, you will want enable a billing account, where you have to give your credit card information. You won't get charged intially since there is a free trial of 3 months during which you get 300 dollars worth of credit. Very pricey, and thinking of looking for other solutions, before the free trial is over.

Google Maps React

Once you get your API key you have everything you need to use Google Maps React. If you want to see the full documentation, it is available on their npm page.

First install the library
npm install google-maps-react

Here are some of the imports that I used for my map component, the required ones being the Map and GoogleApiWrapper.

This is the component itself. I ended up using the markers for marking out where my stores were and obviously the map component intself. The properties of concern for my app were the initialCenter of the map component and position attributes for the markers. I wanted the map to start on the store's location and the markers to mark out the user's location and store's location.

The user's location was using the navigator object available on the browser, and the store's location was using sending parameters of the store's address to the Geocoding API I enabled. Both of these return object literals that have 'lat' and 'lng' properties, that can be passed into the respective component properties to get our desired map configuration.

Last but not least we have our API's export statement, which we need to insert our API key. I simply wrote a note here, but you'll want to hide it in an env file which is git ignored so that it's hidden.

And there you have it! Google Maps on your React app.

Hosting Rails project on Heroku

Allen Shin — Sat, 26 Sep 2020 23:46:14 +0000

After you finished your projects, you want to be able to host your project online to show off to your friends and family, and there's a ton of available options when it comes to hosting your project, including popular cloud based solutions like AWS, which has a lot more customization options. If you want something simple, Heroku has everything you'll want for your hosting purposes. There's a ton of documentation on the Heroku website for how to set up for different languages, but this is what you'll need to do for a Ruby on Rails project.

1) Create a heroku account

Go to https://www.heroku.com/ to create a Heroku account.

2) Create a new Heroku project

After signing in you should be redirected to this homepage. You'll want to create a new heroku project by clicking on the new button in the top right corner.

3) Download Heroku Cli

Go here to download the Heroku Cli onto your machine which will allow you to run heroku command in your console.

4) Login to Heroku

Run heroku login on your console and type in your heroku account credentials to login.

5) Link heroku remote to your existing Git repo

If you don't already have a git repo you'll have to create that first. Navigate to your git repo on your local machine, and run this command

heroku git:remote -a PROJECT_NAME

6) Push to heroku and build.

Run these to start your build

git add .
git commit -m 'commit message'
git push heroku master

7) Make database migrations and seed your data

After your build is successful you can run these to create necessary migrations and seed data.

heroku rake db:migrate
heroku rake db:seed

8) Open your heroku project!

Run heroku open to open your project. If you get something like "Something went wrong on your webpage" you can type heroku logs for more information on your particular error. If you're here, good luck on Stack Overflow.

Getting started with React Native (Windows)

Allen Shin — Sat, 19 Sep 2020 23:49:07 +0000

This week I started working on my first React Native project, and I found the set up to be very simple. Here's how I got my project set up on Windows.

Node JS

First you need to have node installed in order to run npm commands. that you'll need to download your environment files. It needs to be the LTS version and higher than 12. You can download this at the Node website.

https://nodejs.org/en/download/

Expo

After getting Node installed you'll need to run an npm command to download the Expo dependency. You can do this by running

npm install -g expo-cli

This will install the Expo dependency globally allowing you to now run expo commands in your terminal.

Create a new project

After downloading expo you should be able to run this command to create a new expo project

expo init ProjectName

After running this command, there is a potential error you could get which says that expo isn't recognized as an environment variable.

To fix this you have to set your path system variables and add this route %USERPROFILE%\AppData\Roaming\npm.

This tutorial has instructions on how to do that here for different windows versions.

Running your project

When you run npm start you should get something like this in your terminal.

You can now access the developer tools page which allows you to run react native through a number of different mediums. Here are the options they give you.

If you want to test your code through the client, just select the client option and you should get a pop up browser.

If you want to test your code you'll need to download the Expo app on your Android or iOS device, and use your camera to scan the QR code provided on the bottom right. You can switch the type of connection, and for my own case, the only one that worked for me was tunnel. After scanning the code your phone should give you a push notification to open your project in the Expo app.

Welcome to React Native!

Project organization

Allen Shin — Mon, 14 Sep 2020 00:29:52 +0000

I've been working on a grocery delivery application, and I'm proud to say I reached my goal of finishing it this week. I just wanted to spend some time reflecting on what were some things that I thought went well in terms of the overall organization of the project.

As an overview I want to share one of the more helpful tools that I've received when it comes to organizing a project, and that's an overview that holds 3 lesser fields of organization which my lead instructor from FlatIron showed me.

Models

First is your models, or the class structure for your data model. This part involves 3 main concerns that pertain to your data. First you have the data model names and the attributes themselves. Second, you need the associations for your data (how your data is interconnected). Third, you need to spell out your CRUD actions out in plain English. This portion is especially important, because the data is the backbone for your project.

Routes

Next, you have your routes, which also has 3 subsections. First is the fetch requests, which represent routes that you'll need to get data from external sources such as API's. Next, you have your HTTP requests, which is putting your CRUD actions into actual HTTP route methods. Lastly, you'll need to spell out your controller methods. The last two might sound a little repitive, but they are both iterations of your basic CRUD methods but representing your frontend and backend methods, respectively, necessary to implement them.

Frontend

Last, you have your component, props, and state hierarchy, which is specific to React applications, but can probably be applied to other frontend frameworks like Angular. I ended up using Redux in my application so the state management portion made things much simpler, and I didn't need to deal with the whole handing down props and knowing which component would need to hold the state. The components were for the most part straightforward, but one thing to be conscious of is learning to reuse components wherever possible.

Overall, getting this section right the first time and ironing everything out before hand is going to save you a lot of time in the long run. Having the chance to take a look at how everything connects, will be essential in the implementation of the smaller parts of your project. This was a primary theme for me. Whenever I was writing a function, a lot of time could have been saved if I was cognizant of what output I needed, given the where I was sending the information in the application. Having a solid overview, and continuing to refer back to it will be helpful.

There are definitely things you might not be sure about and might have to revise as you go along. For example, one of the biggest time sucks was trying to get the data for my grocery store items. I initially planned on using an API to grab the information, but found out that a lot of grocery store API's require payment. I ended up spending a ton of hours doing research on if there were any free options and even potentially using web scraping as a possibility. After a week of realizing I was getting nowhere, I ended up seeding my own data.

I'm still trying to parse out what I could have done better, because I really wished I could have used some kind of an API service and wish to include an live source of data in the future. Given the circumstances, I think what I learned from this part was that I learn to stay away from rabbit holes as much as possible, by sticking to an MVP (Minimum Viable Product). I still have a lot to work for the project to get to where I want it to be, but focusing on the minimum requirements helped me to make consistent progress.

One other tidbit, which I mentioned before with the components, was to think about how you can reuse components and functions. Having a separate function everytime you do something can lead to a lot of clutter and unnecessary code which is not fun to read or debug. In the future I'm thinking about how I can refactor existing data so that I can try to condense the amount of code I have to write.

Overall I'm very happy with how my project looks, even though I definitely want to work on some of the more fine details. As far as when it came to kickstarting the project, having the overview in mind, and working simply and effectively to implement the backbone helps make solid foundation, which is easy to add to later on.

Learning to love programming to learn programming

Allen Shin — Sun, 06 Sep 2020 00:08:07 +0000

In past weeks, I've been continuing to upload a bunch of articles that have to do with technical concepts that I've been learning from various places like Udemy, Youtube, and Frontend Masters. All of these are great resources, and they have been vital in continuing to learn after finishing my bootcamp. However, with all of the confusing syntax and mazes made of algorithm, it's no wonder why it's difficult to stay motivated. I wanted to reflect on some of my process with you this week.

Particularly in the area of our lives that pertain to looking for work, the most obvious reason why someone would want to work is for money. This is probably the primary reason why most people go to work everyday, and it has to do with the idea of delayed gratification. Work now, so that I can have money to spend later. It can mean that there are times when you would rather to kick back and watch Netflix on a Monday, but you'll go, because you are probably going to get fired if you do that. It's tough to like what you're doing all the time every single day. It's all good though, you just have to get survive until 5, and then you can go home and then you can binge.

To be frank, the carrot on the stick has been a job or money, and to be even more frank, that's probably also why bootcamps are so popular. Hey, easy money! Just take this bootcamp, become a well paid programmer in 3 months! Guess what though? It's been almost a year since I started and I still don't have a job. I put in the hours and hours of work, and then the feeling like there is going to be no reward(job) in the end, has been downright exruciating at times. After a while, a giant Interstellar sized wave made of cynicism and imposter syndrome shows up threatening to overthrow your tiny little boat called 'I want to become a software engineer'.

This challenge has been tough, but the struggle has been a blessing in disguise, because I realized there's something worse than not getting a job. It's thinking that the time you are spending doing whatever work you are doing is a waste of time. What's worse not having a job, is getting that job and then watching the clock every 10 minutes to see how much time you have until you get to clock out. To actually enjoy your job is the central issue, which has to do with a more wholistic sense of meaningful success (and even getting hired).

This week has been a huge breakthrough in finding this kind of enjoyment, and there are three sticking points that have been crucial for me in learning to enjoy programming.

Build Something

Something I've consistently heard since starting to code is that coding is the only way to learn to code. I've understood this to mean that you need to practice actually doing something in order to learn it, but a better context for me to understand this advice is to learn to build something. What is that we are learning to do, type commands on a keyboard? Is it enough to know what a function is and does? No, both of these are irrelevant without the context they hold in a specific program, and to understand the true meaning behind Admittedly, I've learned a lot of facts about programming, but without a larger context to remember them, I have forgotten a lot of them. In order to truly learn something I have to love what I'm learning.

This tip was actually given to me by a software engineer I recently met a Google, who told me that out of everything I could be doing to find a software engineering job, the most important was that I should be working on projects. Ever since I started doing this, I began to notice everything that I was learning sticked much better, because solving an actual problem in your project requires more comprehensive understanding. Also it was easy to stay motivated, because programming is a rare kind of work that offers a sort of instant gratification in immediately rendering your amazing results. Beyond the individual features, building a project gives you a vision, whether it's helping a client with a specific problem, or just making something that looks really cool. Either way, when you care about the problem is when you stay an hour past your designated work hours to continue improving your application.

Overall, I realized this vision is what fuels long term employees to stay at their companies, and also the reason why a lot of employees end up leaving Google after only a couple years. It probably has to do with whether they like what they are building, or if they are even building something at all.

I am a builder

This is somewhat related to my last point, but with a bit of a deeper reflection on my identity. I've always kind of realized this, which is why I was always writing on my resume "I love to build things", but as I mentioned before, a big temptation that comes up is often feeling like you'd rather be doing something else.

Basically I realized, there's nothing I would rather be doing than building something.

It might be tough to wrap your mind around tough ideas, but when you remember that your hard work can create something that wasn't there before, it all becomes worth it. The harder you work and learn the hard stuff, the more splendid your creations can be. Overall, it's really important to remember that you were created for greatness (although may lie dormant). You are meant to do great things, whether that is in building something or in other areas of life.

Stay gritty

Kind of like the recursive title, my final point is a return back from staying motivated to learning. Ultimately, I believe these two things are connected, and they feed off of each other. Initially, it can be hard to stay motivated, because you can't see any results, even in the most simple things. That is where grit and believing you can do it is absolutely necessary, as a sort of firestarter when you're beginning to learn anything. In my opinion, without this kind of attitude, it is impossible to attain the kind of motivation that is necessary to truly love programming.

Obviously the toughest part is dealing with the excruciating feelings of self doubt and not making any progress after hours of time investment. In my experience, these seemingly useless hours are also the most indispensable and are invaluable to growth as a programmer and person. Those hours of trying to find that bug that was a misspelling teach you to not give up on a solution, to be more detail oriented, and that you should probably be more mindful of spelling errors next time. Growing is painful, but sticking with it and finding the joy of overcoming your hardships will reap immense benefits. You got this!

Overview

I feel like these lessons are ones that many people are aware of, but it has been such a livening experience for me, that I wanted to take a break from the usual technical post to share about this progress. As of now, I haven't completed even one project after my bootcamp, but I have really started to enjoy working on a grocery delivery application which I've called BreadBasket. I've made over 50 git commits this week! New personal record! I hope to finish it in this coming month.

Overall, I hope to continue to develop a vision for what I want in the life of software engineering.

Redux Persist

Allen Shin — Sat, 29 Aug 2020 22:12:56 +0000

As I was working on my project this week, I got authentication with Google to work, but I ran across a problem when I tried refreshing my page. I had the code set up so that when my application initializes, the google callback function returns user information which is then passed to my redux store. I previously thought that the redux store would continue to persist the store information as an entity separate from the redux application, but I noticed that all of my user information disappeared on refresh.

After a bit of research, I found that everytime your application renders for the first time, Redux uses the initial state that you set on your reducer function. This includes when your application is refreshed. In order to help witt this issue, I also found there is actually a library to help with this problem called Redux Persist.

The way Redux Persist works is it uses the local storage in your browser to 'persist' your redux state. First let's take a look at how your reducers need to be configured with redux-persist.

Persist Reducer

After importing the usual combineReducers function from Redux to aggregate the reducers, you'll need to take the result and pass it into persistReducer with a persistConfig. In this JSON object, there 2 initial configurations which you need to set. The first is key, which essentially means at what level of your reducer you'll want to start persisting data. For persiting the whole reducer, you'll want to use 'root'. The second is the storage variable which is imported from redux-persist/lib/storage, and is a variable which points to your browser's local storage.

After setting those up, there are a number of different options to customize the persisted state. Two notable ones are stateReconciler and blacklist/whitelist.

stateReconciler has 2 main options, which is hardSet, autoMergeLevel1, and autoMergeLevel2. These options are basically variations of how you want to deal with conflicts in initial state and the incoming state. The first option is going to hardset your incoming state. The second option is the default, and it will return a state with the keys in your initial state, considering any overwrites from your incoming state. Any keys not in the initial state are omitted. The third option is going to do the same and but keys not in inital state are kept.

The other blacklist/whitelist option is used to determine what keys in your reducer you want to blacklist(remove) or whitelist(keep). Using whitelist will make it so that only those keys you included will be persisted.

After configuring your desired options, put the combined reducers and configuration object into the imported persistReducers function and export the result.

Persist Store

With the reducers ready for use, you can now send your modified reducers into the createStore function from Redux to create your store variable. Along with this, you will pass the store variable into a persistStore function which saves your Redux state onto the localStorage everytime your store changes. We will need to export both of these to the index.js file.

Putting it all together

At the root level of your folder, you'll need to wrap your App component with the usual Provider component which will be given the store variable. With Redux persist, you'll also need the PersistGate component which is exported from Redux-Persist and wrap it around the app component one level beneath Provider. This will allow your app to check whether the app has the persisted state saved to the Redux before your app component renders.

With this I was able to get my Redux state persisted, and my user information displayed even after the refresh. You could save information to local storage yourself, but Redux-Persist has so many built in options for persisting Redux state.

Google Oauth2 on Rails w/ OmniAuth

Allen Shin — Sun, 23 Aug 2020 04:58:53 +0000

This week, I tried to focus mainly on my project and started working on the authentication portion of the project. In order to do this, there was an array of different options I could have gone with including the one that I became familiar with at FlatIron. However, I thought that would be a bit boring, and so I decided to go with Google authentication. Nowadays whicever website you go on, you'll find the easy to use on click solution to signing in, where users don't have to go through a tedious sign up page, since Google provides all the authentication information and processes. I want to share the method I chose to implement authentication on my Ruby on Rails application.

Signing up for a Google Developer's Account

First step to implementing google authentication is to get a developer account on their website. Give them necessary the necessary sign up information and once you successfully sign up, you should be redirected to a homepage. Once you get to this page, you should see a credentials page on the toolbar to the left. Click on it, and navigate to this page.

When you get to the page, you should click on the create credentials button at the top of the page. Select the Oauth option for your authentication needs. You'll notice there are other goodies like the API keys, which you can use for a lot of Google's amazing (and expensive) API services.

Once you create the Oauth credential keys, you should get to this page.

Here you need to give your client proper callback urls, which will get access to google's authentication information. Once your app does the typical google authentication requests, your application will need to get back some information, and these urls are the ones that are authorized to receive. You'll notice that there are two different types of urls available, Javascript origins and redirect URIs. The first is for client urls and the second one is for server urls.

After finishing this, you need to format the authentication screen. You'll need to click the oauth consent screen on the toolbar, and get to this page.

Once you're here you'll need to name your app, and determine what scope you want to use, which determines how much of the user's information you'll be able to access. You'll also have to give it a name which your consent screen will display.

Rails Setup w/ OmniAuth

For integrating your Google authentication on your Rails application, you'll first need to include the omniauth gem for google auth. Add gem 'omniauth-google-oauth2' to your Gemfile then run bundle install.

Intializer

Now that you have your gems, let's first start with our environment. In Rails, to set up your environment, you'll need to use your intializers, which are the first things to run in your project file. Create a separate file in the intializers folder and add in this code.

The ENV is referencing the client ID and secret from the client page where you included certain URI's. You'll have to include these somewhere in your Rails application. The way I did it was to include it in an .env at the root of the folder, and then assigned their keys to their respective values. Make sure to include your keys in the gitignore file to not hide them from public view.

Once you do this, you should be able to go to your ROOT_URL + /auth/google_oauth2 which will give you the authentication screen from Google. You can now use this screen to try and sign in to your application with your Google account.

Routes

After you implement your consent screen, you'll need to have a callback route for the Rails server to handle the information that we'll get back from Google on authentication. The convention for these routes are given as you can see here. The callback route for handling the Google info returned will be named auth/google_oauth2/callback, and the case for failure will be named auth/failure. Notice the callback is routed to a sessions controller, where we'll handle creation of a session.

Sessions

First thing that we should notice is we're getting info back contained in the request variable, which has access tokens from our omniauth request. With the access token we'll run the method we will create in our user (shopper) model. With the id of our newly created shopper as the key, we can now create a session for the user. After creating the session, we'll save a token from Google in case we want to access any more user information in the future, and then save that user.

Model

Here we have our shopper model. The method you see here is responsible for checking the email we received on our authorization callback and seeing if that email already exists in our database. If we already have a matching email, it will simply select that user. Otherwise, we will create the user with the given configuration using the information from the google callback, which will be returned as the shopper variable in our sessions controller.

OmniAuth requires session

Up to this point, I had followed the documentation and various tuotorials, but I had been continuing to get this error where it said that we weren't providing the omniauth gem with any session. This was strange since we clearly were creating a session in our session controller. The issue per a stack overflow post seemed to have been with some middleware configuration where we didn't store the session that we had created. In order to fix this we had to add middleware for cookies and storing those cookies, along with insert_after in order to place the middleware in the correct spot. After this code, everything seemed to be running smoothly.

Success!

After all of that we finally got our first user created!

It's my data!

Next Steps

As I continue to work on my project still have some things to figure out:

connecting my frontend to trigger the callback on the backend
ensuring the browser is getting the cookie/session id on the frontend to correctly handle authentication
confirm that multiple sessions can be held at the same time.

Hope to come up with an edit to this article or an update soon. Until next time!

Lazy Loading Images

Allen Shin — Sat, 15 Aug 2020 20:46:06 +0000

This week, I had the opportunity to submit my first interview assignment during my interview process with Sequoia Consulting. The assignment was to create a React Component that was capable of lazy loading, and that utilized the Observer API. Lazy loading as defined by the Wikipedia article is 'a design pattern commonly used in computer programming to defer initialization of an object until the point at which it is needed'. We see it a lot on some of those fancier websites, when an image is loaded as we scroll down to its location. It was really fun to learn about this topic. Let's take a walk through the code!

First concern that we have is to detect where our element is in relationt our viewport. In order to detect this, I used an API availabe in most browsers called the Intersection Observer API. This API service allows us to attach an observer onto specific elements that can detect its position in relation to the viewport. Let's take a look at our code.

So first thing that I did was to set up a state variable with hooks that created a reference to the object. If you haven't read up on references, you can read about them here. As it mentions in the React docs, a good case to use refs would be to select text and to trigger animations, both of which we will do. Also, refs are particularly important for our case, because we are trying to access the actual unique HTML in the DOM elements being generated by our React engine, and so we need to use references for this case.

Sidenote: You also could have used a class component too to utilize use state and componentDidMount, but my assignment required me to use hooks.

Next, I set up a useEffect method, which triggered on intialization. When the component is triggered, we want to start listening to where it exists on the DOM, and to use our Intersection Oberserver API in conjunction with that.

In order to use this Intersection API, we had have to first create a new instance of it which takes two arguments: a callback function, and an options variable which we'll get into later.

First with the callback function, we give this function two arguments which are the HTML elements we want to observe with the entries variable which we will receive, and observer variable, which allows us to perform functions on the observer itself. In our case, we set up the callback function to determine whether the entry (we only had one per component, but with class selectors you can get multiple), was currently intersecting, and if it did intersect, then you would perform a helper function on the entry.target. As you might've noticed, the entry variable the callback function receives has multiple properties like isIntersecting and target among others, which you can use to perform operations on your HTML.

Before we get into the helper function, the options variable is important, because it sets the definition for what counts as an intersection. The first variable is the root variable which gives us the intial 'box' we are trying to use as the viewport. This can be selected using document.querySelector or if you just leave it null it becomes the viewport by default.

The next is our rootMargin variable allows us to make our box bigger (or smaller if you use negative numbers) and adjust the boundaries of your box. You can use an array here which corresponds to the margins for [top, right, bottom, left].

Last but not least, we have the threshold variable which is a number between 0 and 1 and is a ratio that determines what ratio of your element has to be in the root element to trigger a callback function. You can have multiple values in an array for this element and that would trigger the callback function each time that each particular threshold ratio in the array was crossed.

Now that we have everything for our interaction detection and callback function set up, all I had left to do was to actually decide what I want to do with the callback function when it is called. For this, I decided to change the source of the image element from a default image to the url from the Unsplash API and then add a class to it which would perform a transition, which would be considered our image loading action.

This was the CSS for my transition. Yep only 3 lines! First we have a class that has opacity 0, then we make a transition attribute which takes in the value we want to transition, how long it should take, and what style of transition we want. More on transitions here. Then the class we're adding has the target opacity we would like to transition to.

Here's the final result! Very pretty.

Exploration of recusion and iteration (and most of us already know about iterations)

Allen Shin — Mon, 10 Aug 2020 02:16:12 +0000

As is the case with a lot of topics in programming, there is always more than one way to do something, and this can often make things really confusing. Having failed a technical interview, I realized how important to be able to recognize and properly categorize the type of problem and the solution that is most effective for the situation. Time is of the essence in these industries, as a microcosm of what is to be expected as a developer. In an effort to expand my arsenal, I've decided that I really need a grasp of popular grasps, so that I can expand my arsenal and know which ones excel in particular situations. For this I decided that I finally want to understand the differences between recursion and iteration.

The first thing I was surprised to find is that anything that is recursive can be solved using an iterative function, and vice versa. Being comfortable with iteration, after learning this I was tempted to simply continue using the familiar iterative approaches that I have been using already. However, there are some distinct advantages to both approaches. I'm assuming that most people are like me and that they are less familiar with the recursive approach, given how abstract it is. My goal for this article will be to show why and how the recursive method can be prefereable.

What is Recursion?

First the most basic definition of a function that uses recursion is simply that it calls itself. Essentially, just as loop does an operation multiple times, recursion also functions in a similar fashion. It helps to think of the recursive function as the same thing as whatever happens during each iteration.

However, there's a problem that arises when this function can't stop calling itself. Just like you don't want the iterative function to continue to loop until i < infinity, you would always need to have a base case. In the case of our iteration, we usually set some condition like i < 3 in order to indicate how many times we want i to increment and do the operations in the function. Similarly, we would set a condition in a recursion function as well and this will actually result in returning a value, thus resolving that current function call.

Before we dive into the specifics, here's a list of advantages and disadvantages.

Advantages

Recursion offers elegant solutions that are easier to understand
Can solve more complex problems than with just iteration.

Disadvantages

Requires more space, because you need to add to the stack for every recursive call

Recursion power lies in the utilization of the call stack

So the main question, that I've been trying to answer is why is recursion used, and one of the advantages that we listed was that recursion can solve more complex problems. Why is this so? To demonstrate this, I want to use two different approaches to solving a familiar algorithm in DFS, to attempt to explain the different utilities between the two functions.

function traverseDFS(root) {
  let stack = [root]
  let res = []

  while (stack.length) {      
    let curr = stack.pop()
    res.push(curr.key)

    if (curr.right){
      stack.push(curr.right)
    }

    if (curr.left){
      stack.push(curr.left)
    }
  }

  return res.reverse()
}

This is the iterative version of a DFS search algorithm. In this algorithm, we are pushing to a stack, which is an essential portion of doing a 'complex' problem like a binary search tree traversal. Everytime have something in the stack, which is a node, we need to check whether that iteration is going to have a right and a left node. After encountering a situation where there is a left and right node, we need to be able to recall the possibility that there might be another right and left node in the previous right and left nodes we encountered.

A stack can help us do this, by keeping track of every potential right and left node on that stack, and then running through the entire stack and running the same checks on all those potential nodes. Also, since this a DFS traversal, we'll need to use the pop method, to check the most recent item that was put onto the stack(the deepest element first search). This actually also forces us to use a reverse function if we wanted it to check the left side first, since it reverses that as well.

let recursiveBFS = (root) =>{

  if(root.right){
    console.log('right', root.right.value)
    recursiveBFS(root.right)

  }

  console.log(root.value)

  if(root.left){
    console.log('left', root.left.value)
    recursiveBFS(root.left)
  }

}

On the contrary, here is the much simpler method of using recursion in order to do a DFS traversal. In this case, everytime we either run into a right or left node, we're adding another function onto a call stack. So you can imagine that when we first start with a root node, we encounter a right node, then we add that recursiveBFS function onto the stack and we execute it immediately. Until we reach right nodes this will keep happening.

Remember though, even if the binary search tree continues to have right nodes, the first right node is still on the call stack. This is, because it has not yet console logged its value, and it has not checked for whether there is a left node yet. So, it waits for the last right node to be reached at which point, that will encounter no other right nodes, execute the console log, check for a left node, and finish executing when there is nothing left.

What is so great about recursion is you did not need to keep track of that, but as I said earlier the power of recursion lies in the call stack. Whereas, we needed to create one from scratch earlier, we can no store that on the call stack itself. This allows for more complicated function calls as it saves your function on the call stack, until the rest of your iterations finish an intial function, and then finally completing execution when a desired endpoint is reached for all requirements.

I'm not sure if I explained very clearly, but I think this diagram has been very helpful. This diagram essentially displays whats happening on the stack, when you are performing recursion. The problem that's being displayed here is the famous fibonacci recursion problem.

You'll notice that everytime we run into another call of the function, we put that function call onto the top of the stack. Depending on the function that is being called, that function call will remain on the stack until it is finished running. In this case, each function has another call of the function but with the previous input minus 1. Once we reach the base case, we can see how the stack finishes the function call and pops it off the stack.

Recursion is pretty confusing, and there's still many other examples which I haven't looked into yet, but I thought this would show a small bit of potential. There's also great potential for recursion in graphs, which can make recursive calls to a function without the right and left check, but instead for every neighbor, and then every neighbor of that neighbor.

A plan for the technical interview problem

Allen Shin — Sun, 02 Aug 2020 04:51:31 +0000

So last week I wrote about the reflections on my tecnical interview, and I'm glad to say that after a short period of disappointment, I was able to get back on my feet, and really use this failure as fuel. Although I could be looking at things to blame about my situation, it has been a very energizing week, as I continued to push myself, set a high goal, and continue to look at what needs improvement.

As I started to focus again on data structures and algorithms (and I think I was starting to mention this last week with my point on lacking a plan or approach), I've begun to realize that I need to develop a system for doing algorithm problems. I have looked at some approaches from a previous Udemy course and other resources, and from what I've learned I wanted to share what I've assembled as my personal plan of approach to tackle these questions.

1) DON'T start coding first. Read the problem.

So the first step is a stop sign, and for good reason. Personally, I've found it very tempting to just start coding, to check smaller issues. I find this embarassing to admit, but there are times that I've console logged hello, just to make sure that the function in my Leetcode application was working. This is probably not as bad as most people's inclination to just start coding, so especially for me, I've had to stop and remind myself I start to first read the problem and think about what you will be doing first. I read on a Django developer's github "Think more, code less".

2) What are the inputs and outputs?

What are some things to look for as you read your problem? For starters, the input and output might be a good place to start. This is your starting point. Whatever your solution is going to do, knowing where you're starting and where you have to go, will help you clearly define what are the missing elements to close that gap.

3) Find the main point of the solution

Now that you've identified the bookends to your solution, try to formulate the main point of your solution, by finding the main differences between your input and your output. Start asking yourself what is required in delivering this given output. What is the question asking for you to do? There might be a lot of details missing, but to start of by staking some general idea, is very helpful in starting on the right foot to start exploring possibilities for the actual steps.

4) Use visual aids

I found this tip very helpful from a Pramp interview I was a part of. We were working on a problem that involved grids and I was impressed at how quickly he could type up an example grid on the code editor and use it to visualize his solution. You might not have similar skill, but this can be a very useful tool to understand and talk about your solution. It's not that easy to tell a story with lines of code, but it is with a picture. In the case of whiteboard interviews, this is very accessible, but even in other situations, a notepad and pen can do the trick. Especially for all us visual learners, drawing out our thinking can make it easier for everyone, you and your interviewer, to internalize the solution's main point.

5) Write down the steps of the question in comments for a brute force solution

After getting the general idea of what the problem is asking for, I usually start to write comments within the function itself to determine the steps toward a solution. After marking out basic requirements for a function, I usually start with a solution that can be followed in a step by step solution. The biggest challenge will be to find what actual algorithm or tools you will use, you should be able to vocalize your solution with the steps themselves.

6) Test out your solution with brute force solution, with given/imaginary input

After figuring out the steps, I use the steps to test various inputs that are usually given to you. If not, you can just imagine something basic to start with. Taking the input and running through the solution can help you confirm whether the steps you are taking will give you what you expected or not.

7) Begin to code

Finally, after all of that mental work, we can now begin to code. Having laid down much of the groundwork, this part should now be much easier to execute. I usually find this step consists of checking whether the steps and algorithms I used to execute those steps were accurate. Ideally, these should all be ironed out in the 5th step, but I find myself often asking things like "Do I need a for loop or a while loop?" or "Is this conditional statement covering all of the cases that I thought they would cover?". The better you do your prep, the more seamless this portion should be, but I find this often to be a phrase that consists of editting.

8) Modularize your code using the steps you created

One of the steps that I find useful is modularizing your code, which is to break up the problem into smaller steps. It's quite often that we imagine a step to the solution that is too general for the scope of the problem we are trying to solve. One of the most common solutions I find helpful is using a helper function, to try and divide up my work. With helpful names and good organization, it can also be much easier to see what you're doing.

9) Assume Darth Vader is trying to use your code, find weak points

I got this from a Udemy course, and ever since I heard this tip I have imagined an actual Darth Vader throwing all sorts of malevolant inputs into my code. I'd say it's been pretty helpful. Particularly with inputs, you want to make sure that your solution solves for more than the example input that was given to you with the problem. A lot of times I notice the first check in a solution is seeing if the input equals null. That doesn't involve the solution, but that's good code that was written aware of potential Darth Vaders.

10) Think about space and time complexity

Now this is a topic that is too big to cover in one small tip, but in general, it's important to start thinking about ways that you can optimize your solution after you complete it. This is a topic that interviewers will always ask, and it's important that you prepare. It might be tempting to walk away once your code was submitted and you get that green button, but take that "Faster than 5% of submitted solutions" be your motiviation to realize your solution kind of sucks, and you need to rethink your solution. This can be done by identifying repeated work or poor structure. Also, most of the time, solutions have a 'trick' to them, and doing remembering ideal solutions to many problems will be helpful.

Focus and Persevere. You got this!

Technical interviews are hard and so are the questions. They are meant to be difficult, so that they can be a true rubric for whether you are qualified or not. I would say one theme and attitude you should have is focus and persevere. Usually, there's a ton of details you have to keep a track of, and if you're not void of all distractions, it's easy to end up with a half baked solution. Keep practicing, focus, do your best! You got this!

Reflections on my first technical interview

Allen Shin — Sun, 26 Jul 2020 22:23:30 +0000

This week, I took a bit of a break from doing learning new concepts online, because I actually had my first techincal interview!!... I didn't pass it. I think that it was definitely a sign of progress that I was able to land the interview in the first place, but I guess I just wanted to share some of my thoughts on what went right and how I can improve, so that I can share some of my insights with others.

Getting the technical interview

Believe it or not, the first round of interviews was actually more nerve racking for me. To me, the idea of having to talk about who I am, advocate for my software skills, as well maintaining a sense of personability seemed like a juggling exercise. I remember 5 minutes before having to call, I was having a mild panic attack and pacing around back and forth in my room.

I actually had one other opportunity at a behavioral interview
before this, and it actually went really badly. As soon as the interviewer asked me to tell me about myself (which is a que for your elevator pitch), I talked for about 5 minutes about my entire life story and how I got to pick software engineering. I didn't want to repeat the horror story that was my first behavioral interview, and before I went in this one, I kept having flashbacks to the previous interview.

Trying to forget my past experience, the behavioral interview started. I still had a lot of jitters, but it was nice, because the interview was very conversational in tone, and it went very smoothly. There were 3 main points that I think guided this first part of the interview to be successful.

1) Maintain curiosity

I think the thing that made my first interview bad, was I put myself into a kind of spotlight. As soon as the interviewer asked her first questions, I thought that I had been put into an interrogation room. Don't have that mentality! That is setting up yourself for failure, and sending out a lot of awkward energy to the interviewer. The behavioral interview isn't all about you.

It is easy to get into that mentality, because obviously we want to show the interviewer that we are capable engineers worthy of being hired. To counteract this fear, I think most people will say that this is an opportunity for you to interview the company. That is not necessarily how I approach the company, because frankly, I'm not that picky about where I'm trying to work.

Instead I went in with the mentality of being inquisitive specifically about what the person was saying, and asking follow up questions. I wasn't necessarily trying to find out a whole lot about the company (which I feel like can come off as a bit demanding... 'do you have benefits/ free lattes?'). I just decided to treat this like a normal conversation, where if the other person says something, maintaining an inquisitive attitude about what the other person is saying.

I think this kind of easy-going, inquisitive attitude was a big factor in allowing me to calm down, since my disposition towards everything wasn't so high pressure and it gave the sense to the employer that I was personable. Especially

2) Keep things short and simple

The other thing I realized was when the employer asks you questions about yourself you should have your 30 second pitch ready, and remember that your answers don't necessarily have to be very long. This is what screwed me over during my first interview. If they ask about particular experiences give your STAR story(Situation - Task - Action - Result). The interviewer will easily lose interest, and it will also give you the potential to say something off track. You're a hardworking individual passionate about software development through particular experiences. Good.

3) Show interest in programming

This is somewhat similar to the first point, but I would say specifically you need to show somehow that you are interested in programming. Talk about something that you studied that interests you or about one of the projects you do. One of the main things the interviewer in hiring a programmer is to make sure the person enjoys what he does. Again, I think a key factor is just be natural.

Technical Interview

So great I was able to nail down that part of the interview, the next part is the one I failed. As an overview, the interviewer asked me about one of the projects that I worked on, and then we jumped right into the problem. Without getting too much into detail, the problem gave you a list of courses, students, and a table with a many to many relationship between them. We had to write code that went through all the student models and found all the courses that each student was in, how many students

Things I did well:

1) Mindset of having a learning experience

I think my mentality was for the most part good. I think I was much less nervous for this one than the previous one, and I think that was mainly due to my disposition towards this interview as a learning experience. It was much easier to think about it this way too, because the interview would consist of actually coding, instead of just talking about myself.

I think this really helps to calm down to the nerves, but also to solve the problem. The problem itself is a maze full of details which you have to navigate around. Going into the interview with a curious mindset is vital to being able to ask perceptive questions and understand the nature of the problem. This probably seems obvious, but without this mindset to 'learn the problem', it is very easy to approach a problem as a version of another one you've solved before, when small details can make them very different.

2) I explained all my steps

With everything that I did, I tried to write out comments and communicate to the interviewer what I was thinking. Every step that I took, whether it was as simple as looping through an array of users, or finding a particular course, I would vocalize the step and the code that would proceed from that. A software engineer I networked with today told me that one of the most important things that an interviewer is testing for is not whether you know the solution, but whether you can communicate that solution.

Things I did not so good:

1) I lacked an overview/plan of approach

I did explain a lot of things... but I don't think the explanations had continuity. I think that I had a lot of dots that were the right dots. I was saying relevant content... "we need to loop through the list of users", "we should create a data structure", and the interviewer would give me an approval 'yes', only to be followed by a defeaning silence when I gave a lackluster approach to connecting it to the next step of the solution. This lack of connectionshowed partly in the step by step approach of solving the problem itself, but mostly in the lack of a plan before I even started coding. This is probably related to my habit of just jumping into code to guess at a solution when I'm working at something on Leetcode, but I really need to stop doing that and make a habit of getting a detailed overview before starting to solve a problem.

2) I didn't really understand algorithms/data structures, no context

The thing is the problems that I worked on during the interview were very simple questions. One of the things that tripped me up though, was I was worried that I would be asked a dynamic programming question, and so I wasn't able to see that the problem didn't require one. We learn all sorts of algorithms, but we can't just try to remember its content, but how to describe the specific (and perhpas diverse kinds) of situations they are used in. I think as I get back to the drawing board, one of my concerns is trying to remember what kinds of situations algorithms are used in. When starting to study data structures and algorithms, there's definitely the challenge of trying to remember all of them, but if you don't know when and how to use them, you'll be just as lost as if you didn't know them at all.

3) I was a little too relaxed

This is a bit of a contrast to the first positive point I made, but I think I might have taken it too easy. I didn't feel the pressure to come up with a solution, but I just looked at it as a coding session with a buddy. To see things like that definitely help to calm the nerves and reduce the pressure for the very daunting first technical interview, but it also gives the impression to the interviewer that you might not be taking things seriously, which is also bad. Not only that, but you're also being tested on your ability to solve a particular problem, so if you don't actually solve the problem, and only get to two of the three questions like I did, it's not a good look.

Overview

So all in all, it still sucks that I didn't get to the next round, but I'm looking at this as a learning experience. As you prepare and take away from these positives and negatives, I hope you are able to develop the right attitude and tools to pass that infamous technical interview.

Onto the next!