Forem: Jason Park

Building a Gym Logging App

Jason Park — Thu, 20 Mar 2025 20:44:31 +0000

GymLogger was built to replace the manual process of tracking workouts in Google Sheets with a more visual and interactive experience. Instead of relying on spreadsheets, the app provides an easy way to schedule weekly exercises, log workouts, track sets, and see progress over time.

Application Structure

GymLogger is built with React Native and Expo Go, designed to run on iOS without extra setup. It uses SQLite for local data storage, ensuring workouts are logged and accessible even without an internet connection.

Workout Tab

GymLogger is structured around a weekly workout routine, with four exercises scheduled for each of the five weekdays. When the app starts, it automatically detects the current day and displays the scheduled exercises for that day.

Each exercise consists of four sets of 10 reps, and progress is tracked based on total volume.

If all four sets are completed with 10 reps, the app automatically increases the weight for the next session, helping ensure steady progress.

Schedule Tab

The Schedule tab allows exercises to be created and updated for each day of the week. When adding a new exercise, the initial weight and increment value are set, ensuring automatic progression over time. This tab provides full control over workout planning, making it easy to adjust exercises as needed.

History Tab

The History tab organizes past workout logs by week, then day, and finally by exercise for that day. This makes it easy to review progress over time. Logs can be edited or deleted directly from this tab, making it easy to adjust past entries.

Future Improvements

I initially planned to implement a background task that would automatically save workout data to SQLite at the end of each day between 10:59 PM and 11:59 PM local time. However, since Expo Go doesn’t support background tasks for iOS, and workarounds add costs, this became a challenge. For now, data is saved manually through user interactions, but future updates may explore alternative solutions.

Repo Link

GymLogger

Resources

Building a Code Problem Solving Assistant

Jason Park — Fri, 07 Mar 2025 22:13:00 +0000

One of the hardest parts of solving coding problems, especially for beginners, is figuring out the right approach or algorithm. Once you understand how to break down the problem and select an algorithm, translating it into code becomes much more manageable.

CodeScript is designed to help with this exact challenge. It provides structured problem analysis, suggests potential solution approaches, and assists in refining code implementations.

Workflow

The app works by pulling a random coding problem from a database of LeetCode problems and displaying it to the user. Once the user submits their approach, the UI renders a response from the LLM, which analyzes the approach and provides feedback. This helps users validate their thought process before writing code, making it easier to refine their solution.

Application Structure

This is a full-stack app using MySQL, FastAPI, and React. Once all components are completed, we combine everything into Docker Compose.

LLM

The app uses Ollama to run a quantized DeepSeek-Coder:6.7B model locally. The LLM is the most resource-intensive part of the system, as generating high-quality coding problem analysis requires a large model. Running such a model on local machines—especially those with limited RAM—can be challenging, making performance optimizations a key focus.

Once the model is set up, we construct a structured prompt containing the problem details, user submission, and additional context. This prompt is sent to the Ollama server, which returns a response that we send back to the client.

def run_deepseek(problem: dict, submission: str):
    prompt = create_prompt(problem, submission)
    response = ask_model(prompt)
    return parse_response(response)

Backend

The backend provides two main API routes:

GET /problems/random

Fetches a random problem from the database.

POST /generate_feedback

Sends the user's submission to the LLM for feedback.

The generate_feeback route integrates the DeepSeek-Coder:6.7B model through the run_deepseek function. When a user submits their approach, the backend processes the request, passes the problem data and user input to the LLM, and returns a structured response.

To ensure performance and prevent excessive requests, we implement a rate limiter (processing_limiter) and use a lock (request_lock) to manage concurrent LLM calls. The API also includes CORS middleware to allow secure frontend access.

# routers.py

router = APIRouter()

@router.get('/problems/random')
async def get_random_problem_route(db: Session = Depends(get_session)):
    return await get_random_problem(db)

# main.py

app = FastAPI()
add_cors_middleware(app)

@app.post('/generate_feedback', response_model=LLMResponse, dependencies=[Depends(processing_limiter)])
def generate_feedback_route(request: LLMRequest) -> LLMResponse:
    try:
        response = run_deepseek(request.problem_data, request.user_submission)
        return LLMResponse.model_validate(response)
    finally:
        request_lock.release()

app.include_router(problems_router)

Frontend

The frontend is built using Vite with React, providing a fast and lightweight interface for users to interact with the app. When the app loads, it fetches a random problem from the backend using useEffect, ensuring a new problem is displayed on each visit.

When the user submits their approach, the submit button is temporarily disabled to prevent multiple requests from being sent at once. This helps avoid overwhelming the backend and ensures smoother performance. The UI is designed to be simple and responsive, focusing on delivering the problem and feedback efficiently without unnecessary complexity.

The purple button toggles between viewing the current problem and the model's response, the yellow shuffle button goes to the next random problem, and the blue play button generates a response.

Docker Compose

To simplify deployment and keep the app self-contained, we dockerize both the backend and frontend and use Docker Compose to run them together.

The backend is packaged with FastAPI, its dependencies, and the LLM model. A Dockerfile ensures all necessary packages and configurations are set up.
The frontend is also containerized with Vite and React, making it easy to serve the UI without needing additional setup.

Using Docker Compose, we define both services in a docker-compose.yml file, allowing them to start together with a single command.

services:
  backend:
    container_name: codescript-backend
    build: .
    volumes:
      - .:/app
    environment:
      - DOCKER_DATABASE_URL=${DOCKER_DATABASE_URL:-}
    networks:
      - codescript_network
    ports:
      - "8000:8000"
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/"]

  frontend:
    container_name: codescript-frontend
    build:
      context: ../codescript-frontend
      args:
        - VITE_RANDOM_PROBLEM_URL=${VITE_RANDOM_PROBLEM_URL}
        - VITE_GENERATE_FEEDBACK_URL=${VITE_GENERATE_FEEDBACK_URL}
    env_file: 
      - .env
    networks:
      - codescript_network
    ports:
      - "3000:80"
    depends_on:
      backend:
        condition: service_healthy

networks:
  codescript_network:
    external: true

Repo Links

Resources

Building a Lightweight OCR-Powered Receipt Parser

Jason Park — Thu, 27 Feb 2025 18:49:38 +0000

When working with scanned receipts, extracting structured data like dates, items, and prices can be tricky due to varying fonts, layouts, and image quality. ReceiptLogger is a lightweight, local-first application that utilizes PaddleOCR to process scanned receipts efficiently. By integrating PaddleOCR with a Tkinter GUI, the app extracts text from images, parses relevant details, and logs the data into a structured format like a Google Sheet. The goal is to make receipt digitization efficient, even on low-resource machines, ensuring quick and accurate text recognition.

Requirements

ReceiptLogger runs on macOS (tested on an M1 Mac) with Python 3.12.9. It uses PaddleOCR version 2.9.1 for text extraction and Tcl/Tk version 8 for the GUI. Make sure these dependencies are installed before running the app.

App Structure

The app has two main components, the main script containing the Tkinter class for the GUI (main.py) and the helper script that extracts the data from the OCR response (process_data.py).

main.py

main.py handles the core workflow of the app, from receiving images to extracting and storing data. It initializes a folder in Desktop to store uploaded receipt images, processes each image with PaddleOCR to extract text and relevant details, and finally uploads the structured data to Google Sheets for storage. Below are the two main parts of the class, the initialization of key variables and the creation of the UI components.

class ReceiptLogger:
    def __init__(self, root):
        self.initialize_variables(root)
        self.create_ui()

    def initialize_variables(self, root):
        self.ocr = PaddleOCR(use_angle_cls=True, lang='en')
        self.root = root
        self.root.title('ReceiptLogger')
        self.receipts_folder = os.path.join(os.path.expanduser('~'), 'Desktop', '🧾 RECEIPTS HERE')
        self.image_refs = []
        self.receipt_data_refs = []

    def create_ui(self):
        pass

PaddleOCR is an open-source Optical Character Recognition (OCR) tool built on PaddlePaddle, a deep learning framework. It is designed for extracting text from images, supporting multiple languages and text orientations. In ReceiptLogger, PaddleOCR processes receipt images to extract structured data like store names, dates, and item details.

    def extract_receipts(self):
        for widget in self.scroll_frame.winfo_children():
            widget.destroy()

        self.image_refs.clear()

        if not os.path.exists(self.receipts_folder):
            self.status_label.configure(text='❌ Receipts folder not found')
            return

        image_files = [os.path.join(self.receipts_folder, f) for f in os.listdir(self.receipts_folder) if f.lower().endswith('.png')]
        self.status_label.configure(text=f'✅ Found {len(image_files)} receipts')

        for img_path in image_files:
            try:
                ocr_output = self.ocr.ocr(img_path) 
                receipt_data = process(ocr_output) 
            except Exception as e:
                self.status_label.configure(text=f'❌ Error processing receipts: {str(e)}')
                return
            self.display(img_path, receipt_data)

The app uploads extracted receipt data to Google Sheets using the Google Sheets API. It authenticates with a service account, formats the extracted data into rows, and appends them to a specified worksheet. This allows easy access and organization of receipt records in a structured format.

    def upload_data(self):
        if not self.receipt_data_refs:
            self.status_label.configure(text='⚠️ Extract receipts before uploading')
            return

        self.status_label.configure(text='📤 Uploading to Google Sheets...')

        # authenticate and prepare data to append
        credentials = os.getenv('GOOGLE_KEY')
        sheet_id = os.getenv('SPREADSHEET_ID')
        worksheet_name = os.getenv('WORKSHEET_NAME')
        if not credentials:
            self.status_label.configure(text='❌ Google Service Key not found in .env')
            return
        try:
            creds = Credentials.from_service_account_file(credentials, scopes=['https://www.googleapis.com/auth/spreadsheets'])
            sheet = gspread.authorize(creds).open_by_key(sheet_id)
            worksheet = sheet.worksheet(worksheet_name)

            print(f'✅ Successfully connected to Google Sheet: {sheet.title}')
            self.status_label.configure(text=f'✅ Connected to Google Sheets "{sheet.title}"')

            rows_to_append = []
            for receipt in self.receipt_data_refs:
                store = receipt['store']
                date = datetime.strptime(receipt['date'], '%m/%d/%Y' if len(receipt['date']) == 10 else '%m/%d/%y').strftime('%m/%d/%y')
                tax_rate = receipt['tax_rate']
                item_map = {}

                for item in receipt['items']:
                    sku = item['sku']
                    if sku not in item_map:
                        item_map[sku] = {
                            'name': item['name'],
                            'quantity': 1,
                            'price': item['price'], 
                            'taxed': item['taxed']
                        }
                    else:
                        item_map[sku]['quantity'] += 1

                rows_to_append.extend([
                    [
                        store,
                        date,
                        sku,
                        data['quantity'],
                        data['name'],
                        data['price'],
                        tax_rate,
                        data['taxed']
                    ]
                    for sku, data in item_map.items()
                ])

            # append to google sheets
            if rows_to_append:
                next_empty_row = len(worksheet.get_all_values()) + 1
                worksheet.insert_rows(rows_to_append, row=next_empty_row, value_input_option='USER_ENTERED')

                print(f'✅ Successfully added {len(rows_to_append)} rows to Google Sheets')
                self.status_label.configure(text=f'✅ Uploaded {len(rows_to_append)} rows to Google Sheets')
            else:
                print('⚠️ No data to upload')
                self.status_label.configure(text='⚠️ No data to upload')

        except Exception as e:
            print(f'❌ Google Sheets connection error: {e}')
            self.status_label.configure(text='❌ Google Sheets authentication failed')

process_data.py

process_data.py extracts and processes structured receipt data from the OCR output. It identifies the store, extracts relevant details, and calculates tax for each item before returning the final structured data.

def extract_data(response=[]):
    if not response:
        print('🚨 No data to extract')
        return

    stores = {
        'homegoods': 'HomeGoods',
        'marshalls': 'Marshalls',
        'marshalls homegoods': 'Marshalls-HomeGoods',
        'ross': 'Ross',
        't.j.maxx': 'T.J.Maxx',
        'tjmaxx': 'T.J.Maxx'
    }
    store = ''

    if response[0][0][1][0].lower() in stores:
        store = stores[response[0][0][1][0].lower()]
    else:
        for item in response[0]:
            possible_text = item[1][0].lower()
            for key in stores.keys():
                if re.search(rf'\b{re.escape(key)}\b', possible_text):
                    store = stores[key]  
                    break

    if store in ['HomeGoods', 'Marshalls', 'Marshalls-HomeGoods', 'T.J.Maxx']:
        receipt_data = parse_tjx_receipt(response[0])
        receipt_data['store'] = store
    elif store == 'Ross':
        receipt_data = parse_ross_receipt(response[0])
        receipt_data['store'] = store 
    else:
        print('🚨 Not included in the list of stores')
        return {}

    return receipt_data

The helper functions parse_tjx_receipt and parse_ross_receipt handle store-specific receipt formats. These functions are tailored to specific store receipt formats, extracting structured data like store names, dates, items, and prices based on each store’s unique layout. This ensures accurate parsing for supported stores.

Running the App via Automator

To package ReceiptLogger into a macOS app using Automator, create a new Application in Automator and add a Run Shell Script action. Inside the script, add the following three lines:

cd /path/to/ReceiptLogger
source venv/bin/activate
python -m app.main

Save the Automator workflow as an application, then place it in your Applications folder or on your desktop. Clicking it will launch ReceiptLogger without needing to open a terminal.

Resources

Tkinter Documentation – Official Python Tkinter library documentation.
PaddleOCR Quick Start Guide – Getting started with PaddleOCR for text extraction.
You can find the full source code on GitHub ReceiptLogger.

A Beginner's Guide to Open Source Contributions on GitHub

Jason Park — Tue, 02 Jul 2024 23:06:42 +0000

Introduction
Preparation
Ways to Contribute
- Raise an issue or make a suggestion
- Reproduce a reported bug
- Test a pull request
- Solve a reported bug
General Guide
Summary
Resources

Introduction

Being a developer isn’t all about creating cool solo projects. Some of the best repositories out there are open source, meaning they are maintained and updated by other developers over time. Maybe you have heard of some of these: VS Code, Git, React, TensorFlow, Django, etc. These repositories have reached their status because developers come together to fix common bugs and issues.

As a developer, it is crucial to know how to contribute to open source projects on GitHub. Not only does it reinforce our problem-solving skills, but it also allows aspiring developers to be a part of something greater. This blog will introduce how to make contributions to most open source projects on GitHub.

Preparation

Before diving into making changes to any codebase, we must first select the appropriate repo. Selecting a repo as a first-time contributor can be daunting. For those absolute beginners, we could start with the first contributions tutorial. This repo provides step-by-step instructions on how to make your first contribution.

Once you feel a bit more comfortable, we can look for real repos. There are some resources to help you find that right repo. They are listed here:

More advanced folks may want to try different types of projects. A good starting point could be in (GitHub’s Explore)[https://github.com/explore]. Once you have found a repo you are interested in, we can dive into different ways to contribute.

Ways to Contribute

There are many ways to contribute to an open source repo. I will cover the most common ways here, listed in increasing order of difficulty.

Raise an issue or make a suggestion

One of the easiest ways to contribute to an open source project is by raising an issue or making a suggestion. By identifying and documenting a problem or improvement idea in the project’s issue tracker, you help maintainers prioritize and address issues efficiently. When raising an issue, make sure to provide clear and detailed steps to reproduce the problem, along with any relevant context or error messages encountered. Similarly, when making a suggestion for improvement, articulate your rationale and propose practical solutions or enhancements that align with the project’s goals.

Reproduce a reported bug

When encountering a reported bug in an open source project, your ability to replicate the issue is crucial for developers to understand and resolve it effectively. Begin by following any steps or instructions provided in the bug report to reproduce the issue on your own system. This process involves documenting the exact steps taken, any specific configurations or environments required, and noting any error messages or unexpected behaviors encountered. By accurately reproducing the bug and providing detailed feedback, you assist developers in pinpointing the root cause and implementing a targeted fix.

Test a pull request

As developers propose changes to an open source project, they submit pull requests for review and integration. Testing a pull request involves evaluating the proposed changes to ensure they function as intended and do not introduce new issues or regressions. Begin by understanding the scope and purpose of the pull request, reviewing the associated code changes, and considering potential edge cases or scenarios not covered in the initial implementation. Execute relevant test cases, perform integration testing if applicable, and validate the overall impact of the changes on the project’s functionality and performance.

Solve a reported bug

Addressing a reported bug in an open source project involves identifying the root cause of the issue, proposing a solution, and implementing the necessary code changes to resolve it. Begin by analyzing the bug report, reproducing the issue if necessary, and investigating related code areas to understand the underlying cause. Once the problem is identified, devise a strategy to fix it while adhering to project coding standards and practices, typically found in Contributions.md. Implement the solution by modifying the codebase, writing new tests if applicable, and ensuring compatibility with existing functionalities. Collaborate with project maintainers and contributors to review the proposed fix, incorporate feedback, and verify the resolution through thorough testing.

General Guide

For all types of contributions, it is best practice, especially as a beginner, to be able to isolate any changes before submitting a change. Here are the basic steps:

Fork Repo: Once you have found a repo to work on, fork to create a copy of the repo to your GitHub. This can be done by clicking the fork button on the top of the repo home page.
Clone Repo: Clone a copy of this to your local computer. This is done by going to a command line interface (such as Terminal on Mac) and running git clone <SSH>. The <SSH> can be found by clicking on code on your forked repo.
Create New Branch: Create a new branch and switch to it for your specific contribution using git switch -c <name-of-new-branch>.
- Raise an issue or make a suggestion: This step may not be necessary if you’re simply raising an issue or making a suggestion without code changes.
- Reproduce a reported bug: Use this branch to document your steps and any finding while reproducing the bug
- Test a pull request: Use this branch to fetch and test the changes from the pull request.
- Solve a reported bug: Use this branch to develop your bug fix.
Make Changes and Test: Depending on the type of contribution:
- Reproduce a reported bug: Follow steps provided in the bug report and document findings.
- Test a pull request: Run the relevant tests and verify the changes.
- Solve a reported bug: Implement your fix and test it thoroughly to ensure it works as intended.
Commit Changes: Add and commit the changes for submission. This is done by running git add . followed by git commit -m “enter commit message here”.
Push Changes: Run git push to finalize the save into GitHub.
Create a Pull Request: Navigate to “Pull Requests” on your forked repo and click on “New pull request”. Provide a concise explanation of your changes and how they address the chosen issue. If needed, reference the issue number in the description.

Once submitted, project maintainers will review the pull request.

And that’s it. You have now completed your first open source contribution!

Summary

Contributing to open source projects is a rewarding way to improve your skills, collaborate with other developers, and make a meaningful impact on software used by people worldwide. Whether you start by raising an issue, testing a pull request, or solving a bug, every contribution helps strengthen the project and its community. By following the steps outlined in this guide, you’ll be well on your way to making your first open source contribution. Happy coding!

This guide is meant to serve as a learning tool for people who are just starting to learn how to make open source contributions. Please read the official documentation linked below for more information. Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Resources

A Beginner’s Guide to App Deployment via PaaS Provider

Jason Park — Tue, 20 Feb 2024 03:03:34 +0000

Introduction
Basics
Deployment method
- App preparation
- Deploying
Backing and restoring the production database
Conclusion
Resources

Introduction

You’ve spent the last month finishing up your very cool application and now you want to show it off to the world. You try to remember the lecture video on the topic a few months ago but fail to remember the details. Then you look online and come across a blog with the title: A Beginner’s Guide to App Deployment via Paas Provider. Sounds strangely close to exactly what you are looking for.

There are two types of cloud computing services, Platform as a Service (PaaS) and Infrastructure as a Service (IaaS). PaaS simplifies and abstracts away the infrastructure complexity, making it easier to deploy and manage applications. Because of this, it lets developers focus more on coding. On the other hand, IaaS offers more flexibility over the infrastructure components and allows for customization to meet specific requirements. This blog will go over the basics and step-by-step protocol on how to deploy a React-Rails-PostgreSQL app using a PaaS provider, Render. Other popular PaaS providers are Heroku, Google App Engine, and Microsoft Azure App Service.

Basics

When creating our app for production, we undergo several environments depending on the stage of development.

The development environment is when working on the app locally and running code on your personal computer. We are able to use debugging tools like byebug and code analysis tools like ESLint.

The test environment can be utilized when running test runners like RSpec or Jest. The goal is for the code to run as quickly as possible so we can get rapid feedback. Like in the development environment, we are able to use debugging tools when needed.

When we are ready for deployment, we undergo the staging environment. This environment is a replica of the production environment and is used to perform final testing before deploying changes to the live app. We can catch any issues that may have been missed in the testing environment.

Finally we have the production environment. This is post-deployment where the app is accessed by end users. This live environment has to be stable, secure, and highly available.

The staging environment is used after deployment to test the app in a more production-like environment and to serve to end users. Because the steps for staging are generally similar to those of production, we will skip staging for simplicity.

Before diving into the method, we need to think about cost. Although there are free options for many PaaS providers, they are only suitable for smaller and less complex apps. Most free options limit the app in terms of usage so apps that require more resources would probably have to think about the paid plan. Some free plans may also spin-down an app that has been inactive for some time, meaning it will take a minute or so starting back up from this phase. Other things to think about are scalability and performance. This is asking yourself, “how large do I expect this app to be?” and “will this app be performing at the level I want it to for the traffic it will receive?”. Again, using the free plan will limit these things to a significant degree so apps that require more will have to upgrade to the paid plan.

Deployment method

Assuming we have an app ready for production, the first thing we need to do (if not done already), is to link to a remote GitHub repo for the app. Normally, we should already have this during the development stage, but if not, here is a quick rundown:

Create a repo on GitHub
Connect local repo to remote repo with git remote add origin <SSH>
Add, commit, and push code to GitHub with git push -u origin main on the first commit

App preparation

We need to update some of our configuration files. Let’s update database.yml to make sure that we properly set up our production database. If we are using Render, we can connect via url: <%= ENV[‘DATABASE_URL’] %> using the external database url. For now, we can just set up the url key and leave it alone until we have our database ready.

Next we need to update config/puma.rb and config/environments/production.rb.

# config/puma.rb

workers ENV.fetch("WEB_CONCURRENCY") { 4 }
preload_app!

# config/environments/production.rb

config.public_file_server.enabled = ENV['RAILS_SERVE_STATIC_FILES'].present? || ENV['RENDER'].present?

Everytime we deploy the app, we want a script to run that helps build our frontend and backend code. We will create this script file as bin/render-build.sh.

#!/usr/bin/env bash

echo 'Running render-build.sh...'
# exit on error
set -e

# verbose mode
set -x

# builds the front end code
rm -rf public
npm install --prefix client && npm run build --prefix client
cp -a client/build/. public/

# builds the back end code
bundle install
bundle exec rake db:migrate
bundle exec rake db:seed

echo '...finished running render-build.sh'

A couple things to note here. The first line #!/usr/bin/env bash is the shebang line that instructs how this script file should be read. We set the exit on error and verbose mode to help us check the progress of the script as it runs. To build our frontend, we remove the public folder, install dependencies, build our production version, and save that build in our empty public folder. Our backend consists of installing the gems, running the migrations, and seeding the database if it is our first deployment. After our first deployment, we would comment out the bundle exec rake db:seed to avoid duplicate records.

Once we have our script file ready, we want to give it permission to make sure it is executable. On the terminal, run:

$ chmod a+x bin/render-build.sh

Pressing enter on this won’t show any response. To check if the file executable, run:

$ ls -l bin

If there are three x’s in the permission string, we are good to go.

Deploying

Go to render.com and create a PostgreSQL instance as our production database. Make sure that the PostgreSQL version is the same as the version used in development. Create the database and wait for it to be available. In the meanwhile, start a new tab and go back to render.com. This time we want to create a web service. After filling out the requested information, go down to where it says Build Command. Here we want to run our script from above:

./bin/render-build.sh

Our Start Command should run our puma.rb file, like so:

bundle exec puma -C config/puma.rb

Now we need to connect our web service to our local app and our newly created PostgreSQL production database. Remember, to set the Ruby version to that of the app.

To connect to our local app, set the key to RAILS_MASTER_KEY and the value to the secret file master.key in your app. If there is no master.key, we can create one using these steps.

Delete config/credentials.yml.enc
Run this code in the terminal to create a new master.key and credentials.yml

EDITOR="code --wait" bin/rails credentials:edit

To connect to our production database, set another key to DATABASE_URL and the value to the internal database url. On our first tab with the Render database, go to connections to find this url.

That’s it. You have now deployed your first web app along with its database.

Backing and restoring the production database

If you end up using the free version, keep it in mind that on Render, these instances will only be available for a few months. When nearing the end of its life, we need to consider backing and restoring the databases if we want to keep our app alive.

Backing up the database requires us to modify the PSQL connection string (PSQL Command) to run PSQL’s pg_dump. This creates a .sql file of the database. Below is a template of what this string should look like:

PGPASSWORD=your_password pg_dump -h your_host -U your_username --format=custom --no-acl --no-owner your_database > your_database_backup.sql

Replace
your_password with the actual PostgreSQL password shown on Render
your_host with the actual PostgreSQL host shown on Render
your_username with the actual PostgreSQL username shown on Render
your_databse with the actual PostgreSQL database name
your_databse_backup.sql with whatever name you want for the backup file

Copy and paste the PGPASSWORD into the terminal in a directory without a git repo, since we don't want this backup file to get pushed to GitHub.

After creating our backup file, we can now delete the expiring PostgreSQL instance and create a new one, along with the new production database. We can create the database using psql or pgAdmin. Finally, we need to modify the PSQL connection string once more, but this time to run PSQL’s pg_restore. Below is the template once more:

PGPASSWORD=your_password pg_restore -h your_host -U your_username --verbose --clean --no-acl --no-owner -d your_database your_database_backup.sql

Replace
your_password with the new PostgreSQL password shown on Render
your_host with the new PostgreSQL host shown on Render
your_username with the new PostgreSQL username shown on Render
your_databse with the new PostgreSQL database name
your_databse_backup.sql with whatever named your backup file in the previous step

Conclusion

You now know how to deploy your app using a PaaS provider. To review, the steps are:

Connect to a repo GitHub
Update database.yml, puma.rb, and production.rb
Create our build script, render-build.sh and make it executable
Create the PostgreSQL server for our production database on Render
Create the web service on Render

Optional:

Create a backup file using a modified PSQL command to run pg_dump
Restore a database through the backup file using a modified PSQL command to run pg_restore

This guide is meant to serve as a learning tool for people who are just starting to learn how to deploy apps. Please read the official documentation linked below for more information. Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Resources

Render Documentation

A Beginner's Guide to Redux

Jason Park — Mon, 18 Dec 2023 20:09:48 +0000

Introduction
Basics
Implementing with React
File Organization
Conclusion
Resources

Introduction

Frontend state management is an unavoidable concept when creating larger web applications. While there are multiple ways to approach this, one tried and true method is by using a predictable, centralized, and flexible tool called Redux. In React, there are other methods such as the useContext hook that may be easier to set up, yet many developers choose to work with Redux due to its ability to handle complex state interactions in larger applications more effectively. This guide will go over the basics of Redux and how it can be easily implemented in a typical React application using the Redux toolkit.

Basics

Developers use Redux to avoid prop drilling and work with a single source of truth for the application state. Before we go over how to use Redux, we must go over some of the key fundamentals.

The store is the single source of truth that holds the entire state of the application. State represents the current data and the way the application behaves at a given moment. Components or other parts of the application can subscribe to the Redux store to receive notifications about state changes.

All applications using Redux must have reducer functions. These are pure functions that define how the state should change based on the current state and a particular action. There can be multiple reducers for a particular state. When working with React, the reducers are defined in a separate file called a slice.

An action is an object describing how to change state. Developers often use action creator functions to generate these action objects. This becomes particularly useful when there are more complex actions or when we want to abstract away the details of action creation, especially in cases where we might have asynchronous operations in the action creation process.

In order to call for these changes, dispatch functions are used. A dispatch function takes in an action as an argument that provides instructions on how to change the state.

The state is typically immutable. This means that you don't directly modify the existing state; instead, you create a new state object when changes are needed. This helps in tracking and debugging state changes more effectively.

Redux allows the use of middleware, which are functions that can intercept and augment the standard behavior of dispatch. Middleware is often used for tasks like logging actions, handling asynchronous operations, etc.

A simple restaurant analogy can help us understand the Redux system. In this analogy, the store is the restaurant menu, the dispatch function is the act of placing an order, the reducer function is the kitchen, and the resulting state is the meal.

The store displays all the items available for ordering. Just as the menu is a central place for all the food options, the store is a central palace for all the application’s state. When we want to order food (make changes to state), we tell the waiter what we want (dispatching an action) and the kitchen (reducer) processes the request to prepare the dish (update the state). The kitchen follows a recipe (reducer logic) to cook a new dish (updated state). Because the state is immutable, the kitchen doesn't modify the dish, but creates a new one.

Here is a simple example of a Redux set-up in vanilla Javascript:

// Action
const incrementAction = { type: 'INCREMENT' };

// Reducer
const counterReducer = (state = 0, action) => {
  switch (action.type) {
    case 'INCREMENT':
      return state + 1;
    default:
      return state;
  }
};

// Redux Store
const store = createStore(counterReducer);

// Dispatching an action to update the state
store.dispatch(incrementAction);

Implementing with React

Redux can be implemented in React applications easily through the help of some dependencies, namely redux, react-redux, and @reduxjs/toolkit. Here is a step by step protocol on how we can do this.

Create a file named store.js. Here we import configureStore from @reduxjs/toolkit and any reducers we want to use. configureStore is a method that helps us consolidate all our reducer functions. In the example below, we have our store defined and added one reducer called counterReducer, which is defined in a separate file ./features/counter/counterSlice.

// store.js
import { configureStore } from "@reduxjs/toolkit"
import counterReducer from "./features/counter/counterSlice"

const store = configureStore({
    reducer: {
        counter: counterReducer
    }
})

export default store

To make this state available, we provide access by wrapping the application with a special context <Provider> component in index.js, similar to the BrowserRouter component for React router. The <Provider> component has an attribute of store={store}.

// index.js
import React from "react"
import ReactDOM from "react-dom"
import { Provider } from "react-redux"
import store from "./store"
import App from "./App"

ReactDOM.render(
    <Provider store={store}>
        <App />
    </Provider>, 
    document.getElementById("root")
)

Now that we set up our store and gave our application access to it, we need to define the initial state, reducers, and action creators, which are coded in a separate file. We extract createSlice and pass an object with keys of name, initialState, and reducers. It is imperative that we export all the action creators and the reducer itself at the bottom of the file.

// counterSlice.js
import { createSlice } from "@reduxjs/toolkit";

// slice
const slice = createSlice({
    name: 'counter',
    initialState: {
        count: 0,
        running: true
    },
    reducers: {
        increment: state => {
            state.count += 1
        },
        decrement: state => {
            state.count -= 1
        },
        toggleRunning: state => {
            state.running = !state.running
        },
        incrementBy: (state, action) => {
            state.count += action.payload
        }
    }
})


export const { increment, decrement, toggleRunning, incrementBy } = slice.actions
export default slice.reducer

Finally, all we have left is to use the dispatch function in the components that need it by importing useDispatch from react-redux. Remember to also import the action creators from our slice file as well.

// Controls.js
import React from "react"
import { useDispatch, useSelector } from "react-redux"
import { decrement, incrementBy, toggleRunning } from "./counterSlice"

function Controls() {
    const dispatch = useDispatch()
    const running = useSelector(state => state.running)

    function handleMinusClick() {
        dispatch(decrement())
    }

    return (
        <div>
            <button id="minus" onClick={handleMinusClick}>-</button>
            <button id="plus" onClick={() => dispatch(incrementBy(10))}>+</button>
            <button id="play" onClick={() => dispatch(toggleRunning())}>{running ? "⏸" : "▶️"}</button>
        </div>
    )
}

export default Controls

In our example above, we have the onClick event listeners defined for each button. Within the event listeners, we call our dispatch function while passing our action creator as the argument.

So now we know how to update state, but how can we access the state to use in our components? In the provided example, we utilize the useSelector hook from react-redux to access and utilize the state in our components. Specifically, we set the variable running using useSelector, and it corresponds to the running key in the initial state object defined in our counterSlice. As per the counterSlice example, the initialState object includes a key running set to true. This mechanism allows us to effortlessly access and utilize state variables throughout our application.

File Organization

Organizing files in a Redux and React application is crucial for maintainability and scalability. A common practice is to structure the project based on features or modules. Each feature typically has its own directory containing related components, actions, reducers, and selectors. For instance, a "counter" feature might have files such as Counter.js for the component, counterSlice.js for the Redux slice (including actions and reducer), and possibly Counter.css for styles. This modular organization promotes encapsulation and makes it easier to locate and update code associated with a specific feature. Additionally, there is often a centralized store directory that houses the Redux store configuration, combining all slices into the root reducer. To enhance readability, consider using subdirectories within features for further categorization. Overall, a well-organized file structure not only improves code maintainability but also facilitates collaboration and ensures a logical separation of concerns in your Redux and React application.

Conclusion

This beginner's guide has provided the basics introducing Redux and its integration with React, offering a robust state management solution for larger web applications. By understanding the fundamental concepts of the Redux architecture, such as the store, reducers, actions, and the dispatch function, developers gain a powerful tool to manage and update application state effectively. By adopting Redux, developers can streamline state management, simplify complex interactions, and build more resilient and scalable React applications.

If you're eager to delve deeper into Redux, refer to the official Redux documentation for comprehensive resources and guidance on advanced topics. Happy coding!

This guide is meant to serve as a learning tool for people who are just starting to learn Redux in React. Please read the official documentation linked below for more information. Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Resources

Redux

A Beginner’s Guide to Authentication and Authorization in Rails

Jason Park — Fri, 01 Sep 2023 18:56:08 +0000

Introduction
Authentication vs. Authorization
Cookies and Sessions
BCrypt
Signing Up
Logging In
Auto Login
Logging Out
Authorizing
Conclusion
Resources

Introduction

As we expand our app development knowledge, let's dive into the world of authentication and authorization in Ruby on Rails. In this guide, we'll cover the essential concepts and tools you need to build secure web applications. Authentication and authorization are fundamental to ensuring the right users access the right resources. We'll explore topics like cookies and sessions, BCrypt for secure password handling, user sign-up and logIn processes, auto-login mechanisms, and user logout procedures with examples. Plus, we'll delve into the art of authorizing actions to secure the backend server from unwanted requests. Let's get started on this crucial aspect of web app development!

Authentication vs. Authorization

First we need to define the differences between authentication and authorization.

Authentication is the process of verifying the identity of the user. In other words, we are checking to make sure the users are who they say they are.

Authorization is the process of allowing certain users to gain access to certain features in the app.

Basically, authentication answers the question of “who are you?” while authorization determines “what are you allowed to do?” The security of any web application lies in its ability to authenticate and authorize users effectively, safeguard sensitive data, prevent unauthorized access, and continuously adapt to emerging threats.

Cookies and Sessions

While there are many ways to authenticate users, we will be exploring how to achieve this via cookies and sessions. Cookies and sessions are fundamental tools in web development for maintaining user state and enhancing security. They allow us to keep track of user data and interactions throughout their visit to our application.

Cookies are small pieces of data that a web server sends to a user’s browser (server to client). These data packages are domain-specific and stored on the user’s device after the user has visited a website or a web application so that on subsequent visits, the server quickly knows who the client is.

Cookies serve various purposes including storing information such as user authentication tokens, shopping cart contents, or user preferences. They are stored on the client-side in the browser and sent back to the server with each HTTP request, allowing the server to recognize and remember the user. In the context of authentication, cookies often store user session information to keep a user logged in across multiple interactions with a web application.

Sessions are a server-side mechanism for maintaining user state. Unlike cookies, which are stored on the user’s device, sessions are stored on the server.

When a user interacts with a web application, a unique session identifier is typically stored in a cookie on the user's device. This session identifier allows the server to associate subsequent requests from the same user with their session data stored on the server. In the context of authentication and authorization, user session data can include information like the user's ID, which are used to determine what actions the user is allowed to perform within the application.

Here is how this works:

User visits a website/application and logs in.
Server generates a session on the server-side and sends a cookie containing a session identifier to the client's browser.
The client's browser stores this cookie.
On subsequent requests, the client's browser automatically sends the stored cookie with the session identifier back to the server.
The server uses this session identifier to retrieve the user's data from its session storage and identifies the user.

In order to enable cookies and sessions in our Rails application, there are some things we need to set up.

In our config/application.rb:

module MyApp
    class Application < Rails::Application
        # Add cookies and session middleware
        config.middleware.use ActionDispatch::Cookies
        config.middleware.use ActionDispatch::Session::CookieStore

        # Use SameSite=Strict for all cookies to help protect against CSRF
        config.action_dispatch.cookies_same_site_protection = :strict

        # Initialize configuration defaults for originally generated Rails version.
        config.load_defaults 6.1

        # Only loads a smaller set of middleware suitable for API only apps.
        # Middleware like session, flash, cookies can be added back manually.
        # Skip views, helpers and assets when generating a new resource.
        config.api_only = true
    end
end

In our app/controllers/application_controller.rb:

class ApplicationController < ActionController::API
    include ActionController::Cookies
end

Once these files are properly set up, we can use cookies and sessions.

BCrypt

When a user first signs up, the server must store that information in their databases. However, one very important concept to keep in mind is that passwords are never saved as a plain text in any databases due to security risks. A standard method of storing passwords is through encryption via salting & hashing.

Salting is the process used to enhance the security of password storage. This process involves a random and unique piece of data called “salt”, which is generated and combined with every password before applying the hash function. This ensures that two users with the same password will have different values due to the unique salts.

Hashing is a one-way function that transforms the password into a fixed-length string of characters called “hash”. After a password has been salted, it undergoes the hashing process.

The primary characteristic of a good cryptographic hash function is that it's irreversible, meaning you can't reverse the process to retrieve the original password. Even a small change in the input data should produce a significantly different hash. In the context of password security, the user's password is salted and hashed and then stored in the database. When a user attempts to log in, their entered password is hashed again, and the resulting hash is compared to the stored hash in the database. If they match, the login attempt is successful.

Here is how it works:

We have two users John and Jane with the same password, “Password123”.
When they sign up, they are given two unique salts: John gets “sd9f6” and Jane gets “3x41p”.
The salting process turns John’s password into “Password123sd9f6” and Jane’s into “Password1233x41p”.
The hashing process via a secure hash function turns John’s salted password into “d3f4e5g6h7i8j9k0” and Jane’s into “m1n2o3p4q5r6s7t8”.
The server stores John’s salt “sd9f6” and hashed password “d3f4e5g6h7i8j9k0” and Jane’s salt “3x41p” and hashed password “m1n2o3p4q5r6s7t8”.
When John or Jane logs in, the salt and hash function converts their password input into the hashed version. If the hashed passwords match, they are successfully logged in.

To simplify this process as web developers, we can use a Ruby gem, BCrypt. BCrypt provides the has_secure_password method for the User model. This method:

Automatically salts and hashes user passwords
Automatically adds a password_confirmation attribute to the model (used for signing up and updating passwords).
Automatically adds validations for password-related inputs, such as its presence and any other specified requirements (minimum length, required characters, etc)
Provides the authenticate method for the Sessions controller.

All these features can be utilized after including the has_secure_password method in the User model.

class User < ApplicationRecord
    has_secure_password
end

One last thing we need to do before we move on is to add the password_digest attribute as a string to our User model. This is where our salted and hashed passwords are stored. Once we include this attribute, BCrypt will automatically manage the passwords in a secure way.

Signing Up

To set up the sign-up logic in Rails, we first need to create the appropriate route in config/routes.rb.

Rails.application.routes.draw do
    # signing up
    post '/signup', to: 'users#create'
end

Since we are creating a new User instance, we need to have the route point to the users#create controller action.

class UsersController < ApplicationController
    # post '/signup'
    def create
        render json: User.create!(user_params), status: :created
    rescue ActiveRecord::RecordInvalid => e
        render json: { errors: e.record.errors.full_messages }, status: :unprocessable_entity
end

    private

    def user_params
        params.require(:user).permit(:username, :password, :password_confirmation)
    end
end

In our users#create action, we:

Create a new instance of the User model and save it to our database using the sister method create!(). This allows for Rails to catch any exceptions raised by our rescue clause.
Utilize strong parameters, which are defined under the private methods. We make sure to include both the :password and :password_confirmation attributes in the permitted params.
Make sure to include the status: :created to let the browser know that the User was successfully created.
Include the rescue ActiveRecord::RecordInvalid => e to catch any invalid records. We render this error message in a hash and set the status: :unprocessable_entity.

If we want to have the user automatically log in after creating a new account, we need to set up the login mechanism in our backend and create a new session after the frontend fetch post request.

Logging In

As with the sign up process, we first need to make a new route for this controller action.

Rails.application.routes.draw do
    # signing up
    post '/signup', to: 'users#create'
    # logging in
    post '/login', to: 'sessions#create'
end

This time, we point to our sessions controller. Remember, that when users log in, they must request for the server to create a new session that they can store server-side and refer to when they receive the cookie with the session identifier. For this reason, our controller action will be sessions#create.

class SessionsController < ApplicationController
    # post '/login'
    def create
        user = User.find_by(username: params[:username])

        if user&.authenticate(params[:password])
            session[:user_id] = user.id
            render json: user, status: :created
        else
            render json: { error: 'Invalid username or password' }, status: :unauthorized
        end
    end
end

In our sessions#create action, we:

Use the .find_by() method on our User model to find the appropriate user by the username.
Set up a conditional using the user&.authenticate(params[:password]) method. The &. is a shorthand way of saying “if the user object exists, invoke the authenticate(params[:password]) method on it. Otherwise, return nil.”
Create a new session hash with the key :user_id and value set to the actual user id (user.id) if the conditional is true. This hash typically represents a session token or identifier, which is essential for subsequent authenticated requests.
Render a response with the status: :created if the conditional is true. This response usually contains the session-related information.
Render an error message “Invalid username or password” with status: :unauthorized if the conditional is false.

Once this controller action is set up, we can make a fetch post request from our frontend whenever we need to create a session (log in). If we have our sign-up logic set up, it is typical for the frontend to automatically log in, so the frontend can utilize this fetch request at the end of the sign-up process as well.

Auto Login

When the user reloads a page or closes and reopens the browser, it typically starts a new browsing session. This means the session cookie from the previous session is no longer available, and the server can't associate the new request with the old session. Instead of having the user enter their credentials every time, this feature allows for the user to maintain their logged in status through page reloads.

Like before, we start by creating a new route for a new controller action.

Rails.application.routes.draw do
    # signing up
    post '/signup', to: 'users#create'
    # logging in
    post '/login', to: 'sessions#create'
    # auto login
    get '/me', to: 'users#show'
end

This time, we point to the users#show action since we are looking for an existing user instance.

class UsersController < ApplicationController
    # post '/signup'
    def create
        render json: User.create!(user_params), status: :created
    rescue ActiveRecord::RecordInvalid => e
        render json: { errors: e.record.errors.full_messages }, status: :unprocessable_entity
    end

    # get '/me'
    def show
        render json: User.find_by!(id: session[:user_id])
    rescue ActiveRecord::RecordNotFound
        render json: { error: 'Not authorized' }, status: :unauthorized
    end

    private

    def user_params
        params.require(:user).permit(:username, :password, :password_confirmation)
    end
end

In our users#show action, we:

Use the find_by!(id: session[:user_id]) method to find the existing user by its id.
Render the error message with status: :unauthorized if the user is not authenticated (if the session has expired or the user is not logged in).

With this set up, we make sure our frontend triggers a fetch get request to this route on start-up. On React, this can be done using useEffect(() => {}, []).

Once we are able to retrieve the user information from the backend, we can properly set up our frontend to save our user state. On React, this can be done using useContext() to persist this data throughout our components.

Logging Out

Since we created a new session when logging in, we need to delete that session[:user_id] for logging out.

Rails.application.routes.draw do
    # signing up
    post '/signup', to: 'users#create'
    # logging in
    post '/login', to: 'sessions#create'
    # auto login
    get '/me', to: 'users#show'
    # logging out
    delete '/logout', to: 'sessions#destroy'
end

class SessionsController < ApplicationController
    # post '/login'
    def create
        user = User.find_by(username: params[:username])

        if user&.authenticate(params[:password])
            session[:user_id] = user.id
            render json: user, status: :created
        else
            render json: { error: 'Invalid username or password' }, status: :unauthorized
        end
    end

    # delete '/logout'
    def destroy
        session.delete :user_id
        head :no_content
    end
end

In our sessions#destroy action, we:

Use the .delete(:user_id) method to delete the session[:user_id].
Send an empty head with :no_content.

Authorizing

To add another layer of backend routing security, we want to restrict access to most of our controller actions to those who are authorized. To restrict all controller actions, we must create a custom method in the application controller using before_action.

class ApplicationController < ActionController::API
    include ActionController::Cookies
    before_action :authorize

    def authorize
        return render json: { error: "Not authorized" }, status: :unauthorized unless session.include? :user_id
    end
end

This custom method authorize sends an error message “Not authorized” whenever the user tries to access a controller action before logging in. However, there are some actions that must be exempt from this.

If we think about it, we need to allow the user to be able to sign up and log in without this method stopping them. So we need to create exemptions for these actions. Here is what our final users and sessions controllers should look like.

class UsersController < ApplicationController
    skip_before_action :authorize, only: [:create]

    # post '/signup'
    def create
        render json: User.create!(user_params), status: :created
    rescue ActiveRecord::RecordInvalid => e
        render json: { errors: e.record.errors.full_messages }, status: :unprocessable_entity
    end

    # get '/me'
    def show
        render json: User.find_by!(id: session[:user_id])
    rescue ActiveRecord::RecordNotFound
        render json: { error: 'Not authorized' }, status: :unauthorized
    end

    private

    def user_params
        params.require(:user).permit(:username, :password, :password_confirmation)
    end
end

class SessionsController < ApplicationController
    skip_before_action :authorize, only: [:create]

    # post '/login'
    def create
        user = User.find_by(username: params[:username])

        if user&.authenticate(params[:password])
            session[:user_id] = user.id
            render json: user, status: :created
        else
            render json: { error: 'Invalid username or password' }, status: :unauthorized
        end
    end

    # delete '/logout'
    def destroy
        session.delete(:user_id)
        head(:no_content)
    end
end

The skip_before_action allows us to exempt the sign up and log in actions from our custom authorize method.

Conclusion

We’ve explored critical concepts of authentication and authorization in the context of web application security. We've established the importance of distinguishing between these two processes, ensuring that only authorized users can access protected resources while allowing for efficient authentication processes. Cookies and sessions were examined as tools for managing user sessions securely. Additionally, the use of BCrypt for password encryption was discussed, enhancing application security. By implementing these practices and understanding their roles, developers can build robust and secure web applications, safeguarding user data and privacy.

This guide is meant to serve as a learning tool for people who are just starting to learn authentication and authorization mechanisms in Rails. Please read the official documentation linked below for more information. Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Resources

Rails Documentation on Sessions and Security
SameSite Documentation
BCrypt Documentation

A Beginner's Guide to Active Record

Jason Park — Wed, 07 Jun 2023 20:03:03 +0000

Introduction
Basics
Getting started with Active Record
- Set up Gemfile
- Create models and associations
- Create new migrations
- Migrate changes and check status
Next steps
Conclusion
Resources

Introduction

Active Record is an essential component of web development that simplifies the interaction between a Ruby application and a relational database. It is an Object-Relational Mapping framework that provides mapping database tables to Ruby classes and enables developers to perform common database operations using familiar object-oriented syntax. With Active Record, we can easily create, retrieve, update, and delete records in the database without having to write raw SQL queries. This guide will walk you through the basics of Active Record, including setting up the necessary gems, defining models and associations, creating database migrations, and performing database operations.

Basics

A web application can typically be broken down into three parts: the model, the view, the controller. This is known as the Model View Controller architecture.

Model View Controller (MVC) is a pattern in software development that helps promote a clear separation of concerns and reusability of code.

The model is responsible for data persistence and management. The view is how that information is presented to the user via HTML, CSS, and JavaScript. The controller acts as an intermediary between the model and view, handling the routing, requests, and coordination of data flow. For this guide, we will focus on the model in MVC.

The model represents the database in our application. As developers, we want to be able to access these databases through code by implementing object-relational mapping via Active Record.

Object-Relational Mapping (ORM) is the concept of using an object-oriented programming language (Ruby) to access relational databases (SQLite3).

Active Record is an ORM framework represented as a Ruby gem. By abiding by its conventions, it allows us to simplify database configurations in Ruby-based applications.

A fundamental concept of ORM (and Active Record), is the mapping between models that represent object-oriented entities and database tables. We can view the model object as the database table and instances of that object as rows/records on that table. Following the logic, it makes sense to present the object’s attributes as table columns. In addition, every table has a column for the primary key ID that is unique to every instance. Depending on their association with other tables, they may include a foreign key ID as well. The foreign key is used to establish relationships between other tables.

The two most common ways tables relate to another is via a one-to-many or many-to-many relationship.

One-to-many relationship is when one instance of a model connects to many instances of another model. A user can have many games so there is a one-to-many relationship between the User model and the Game model.

Many-to-many relationship is when one instance of a model connects to many instances of another model and vice versa. A student can enroll in multiple courses and every course contains multiple students so this is a many-to-many relationship.

For example, if we want to create an app where users can browse a list of cities to see posts about that city, we can think about two models, City and Post. Each of these models can be represented as a table with each row representing a specific city or post. There is a one-to-many relationship between City and Post (a city has many posts and a post belongs to a city), which means that the posts table must have a foreign key that matches a primary key of a city.

Getting started with Active Record

Steps:

Set up Gemfile
Create models and associations
Create new migrations
Migrate changes and check status

Set up Gemfile

The first thing we need to do is to make sure we have the Rake and Active Record gems included in the Gemfile. For more information on these gems, please visit the main website for each library.

Once the Gemfile is set up, run bundle install on the CLI to create Gemfile.lock.

Create models and associations

When creating models, we need to have it inherit from ActiveRecord::Base. This gives our models access to commonly used methods for data manipulation. Within the class, we define its association with the other model. When using Active Record, it is crucial to use the correct conventions. When naming models, it must be singular and capitalized.

class City < ActiveRecord::Base
    # a city has many posts
    has_many :posts
end

class Post < ActiveRecord::Base
    # a post belongs to a city
    belongs_to :city
end

For a more comprehensive list of ActiveRecord::Base methods, please visit this website.

Create new migrations

Once the models are created, we need to create the database using rake and migrations.

Rake is a tool that allows us to automate certain tasks. By writing these task shortcuts inside Rakefile.rb, we can execute them using a CLI with quick commands.

Migrations are an Active Record feature that provides version control for database changes. It produces a blueprint for database creation and manipulation.

To create a new migration, we run rake db:create_migration NAME=<description_of_change>. This will create a new migration file and defines a class of that inherits from ActiveRecord::Migration. It will automatically name the file with the datetime it was created.

In the case of our example, we would run rake db:create_migration Name=create_cities and then another for the Post model. Within the class, we write the code for the creation of our table. Here is how that looks:

class CreateCities < ActiveRecord::Migration[6.1]
  def change
    create_table :cities do |t|
      t.string :name
      t.string :population
      t.string :image
      t.string :country
    end
  end
end

class CreatePosts < ActiveRecord::Migration[6.1]
  def change
    create_table :posts do |t|
      t.integer :city_id
      t.string :category
      t.string :title
      t.string :body
      t.timestamps
    end
  end
end

We define a method change by invoking create_table (inherited from ActiveRecord::Migration) and passing in the table name. When naming tables, the word is in all lowercase and is pluralized. We map each attribute to a column by setting up its data type and name. We do not need to manually create the id column since it is automatically generated when adding a new record.

Migrate changes and check status

Once we have our initial migration files, we can run rake db:migrate to execute the changes. Active Record will automatically run each migration file in order of creation and simultaneously create a schema.rb file. This is where we can check to make sure the tables are created properly with the appropriate columns.

Running rake db:migrate:status allows us to check the status of our migrations. It provides information about which migrations have been applied to the database. When a migration is marked as "up," it means that it has been successfully executed and applied to the database whereas “down” would mean it has not been applied or has been rolled back.

This way of version control allows developers to track the migration history and easily identify the current state of the database schema. By knowing which migrations have been successfully applied, developers can ensure that the database structure is up to date and consistent with the application's codebase. It provides a systematic approach to managing and applying changes to the database over time, making it easier to collaborate with other developers and maintain the integrity of the database schema across different environments.

Next steps

Once we have created our models and corresponding database tables with columns defined, our next steps would be to seed the database and initiate the server. We can create seeds.rb, whose sole purpose is to fill our tables with data. Although we won't go over these in detail, there are some ways to achieve this.

Using randomly generated data via Faker
Grabbing data from a public API via RestClient
Scraping data from HTML via Nokogiri

Finally, before we open our server, we must have our controller (in our MVC paradigm) set up. This middle layer dictates the communication between our client (view) and server (model). An easy way to do this is through Sinatra, a web framework built on top of Rack. Sinatra provides a simple way to set up our routes using a configuration file (config.ru) and the HTTP request handling file (application_controller.rb).

Conclusion

Active Record, as an ORM framework, plays a crucial role in simplifying database interactions and promoting efficient development practices. Migrations provide a systematic approach to managing database changes, allowing developers to track the migration history and maintain the integrity of the database schema. With the ability to automate tasks using Rake and easily check the status of migrations, developers can ensure that their database structure is up to date and consistent. By mastering the fundamentals of Active Record and migrations, developers can enhance their productivity, collaborate effectively, and build robust web applications with ease.

This guide is meant to serve as a learning tool for people who are just starting to learn Object-Relational Mapping. Please read from the official Active Record website for further detail. Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Resources

A Beginner's Guide to React

Jason Park — Wed, 29 Mar 2023 03:29:34 +0000

Introduction
Components
JSX
props
Conclusion
Resources

Introduction

As we dive further into web development, we begin to learn about React by Facebook. When beginners start coding, they do so imperatively but React approaches coding declaratively. These are different programming paradigms that change the way programmers code.

Imperative programming is when the programmer explicitly specifies each step. Declarative programming focuses on the task that needs to be done and does not specify how it is achieved. In other words, imperative programming is described as “do this then do that,” whereas declarative programming is described as “tell me what you want and not how to get there.”

There are many benefits to declarative programming:

It is easier to scale and incorporate into larger programs.
It is easier to debug and maintain the code.

Components

In order to program declaratively, React takes advantage of components that each have a specific role in the overall application.

Components are different groups of code that work together to create a functional React application. For example, one component can take care of the main menu, while another renders from a database API. By separating these “building blocks” of code, programmers can work on specific functions of the app more easily than they could for a monolithic block of code.

Components are structured in a hierarchy that can be illustrated in a wireframe. Here is an example of a component hierarchy:

In the example above, the App.js component is at the top-level. Other common components are the NavBar.js (containing code to render the navigation menu) and Home.js components (containing code to display the Home page). The remaining components work together in tandem to create the functionality of the application.

The lines between the components indicate how they are connected. For example, the NavBar.js and Home.js components are child components of App.js and sibling components to each other. RecipeItem.js is a child component of RecipesList.js, which is another child component of App.js. These relationships illustrate how information is transferred from component to component.

React components require that we import some crucial modules from a library of dependencies.

Dependencies are a collection of pre-written code modules that the program needs to function properly.

To initialize React, we need to import the React and ReactDOM modules from the react and react-dom dependencies, respectively. ReactDOM is invoked with two arguments. The first is the React component being rendered and the second is the location to render it at. This can be done in index.js. We can think of this as our starting file.

import React from 'react';
import ReactDOM from 'react-dom';
import App from './components/App';

ReactDOM.render(<App />, document.getElementById(‘root’));

App.js is the top-level component from our example above. From there, all the other components are called in the order shown in the hierarchy.

Components also require an export statement to be able to transfer data to either its parent or child component.

A typical export statement in most components is placed at the bottom of the .js file.

export default App;

Think of the export default line as a return statement for the component itself. Speaking of return statements, what do these components return?

JSX

When we code imperatively, we must make all the changes in the HTML file ourselves. Whenever we need to manipulate the DOM (Document Object Model), we must write specific code step by step to detail it out. For example, we may need to create a new element, update that new element then finally append it to the DOM to see changes in our browser. With React, we code declaratively meaning we do not need to write all that out. Instead, we can tell React to change the HTML by returning JSX.

JSX (JavaScript XML) is a JavaScript extension that allows us to write HTML-like code in our JavaScript file. This opens the door to directly manipulating our DOM, without having to tell it to create, update and append.

Each component is essentially a function that returns some JSX. This JSX is rendered on a virtual DOM, through the return and export default statements, whenever the component is called. By going through a virtual DOM, React calculates the minimum number of changes needed to update the real DOM. This results in a faster and more efficient render. Here is a simple example:

import React from "react";

function Home() {
    const name = "John";

    return (
        <div id="home">
            <h1>Welcome to Recipe Journal!</h1>
            <h3>Click on "Recipes" to see a list of recipes.</h3>
            <h3>Click on "Add Recipe" to add a new recipe to the list.</h3>
            <h3>Let's start cooking, {name}!</h3>
        </div>
    );
}

export default Home;

It is convention to capitalize the names of functions that represent components. This helps to distinguish them from regular HTML elements and other functions in your code. It is important to remember to make sure that the function returns only one element. In our example, we return one <div id=”home”></div> with multiple elements inside.

Whenever we want to code JSX, we use parenthesis around it. If we need to go back to JavaScript inside our JSX, we need to use curly brackets. In our example, we need access to the variable name inside our last <h3> tag so we encase {name} in curly brackets.

props

If we want to make our code more dynamic, we introduce the use of props.

props (short for properties) are a tool for passing information from a parent to child component.

When a parent component renders a child component, it can pass data to the child component by providing it as props. The child component can then access and use this data as needed.

When we want to run a component, we go to its parent component and invoke it. To do this, we must import the child component, like we would with any necessary modules.

import React from "react";
import RecipeItem from "./RecipeItem";

function RecipesList() {
    const currentRecipe = {
        name: "Pizza",
        servings: 3
    }

    return (
        <div>
            <RecipeItem recipe={currentRecipe} />
        </div>
    );
}

export default RecipesList;

We define the currentRecipe object with two keys. In our return statement, we call the RecipeItem.js component and pass down currentRecipe as recipe. Think of these as arguments for RecipeItem.js. Now let’s look at RecipeItem.

import React from "react";

function RecipeItem({ recipe }) {
    return (
        <div className="item">
            <h3>{recipe.name}</h3>
            <h3>{recipe.servings}</h3>
        </div>
    );
}

export default RecipeItem;

Inside the parameter, we pass the prop as recipe, making sure to destructure it correctly by using curly brackets around it. This gives us access to that object, where we can grab the values of its keys as we would with any object.

Conclusion

React is a popular JavaScript library for building user interfaces for all kinds of different web and mobile applications. It uses declarative programming that allows us, as programmers, to describe what we want in our code without explaining how to get there. It makes use of components and props to return JSX in a way that makes it easy to manipulate the DOM via virtual DOM. Because of its efficiency, it has garnered a large active community and ecosystem, making it very appealing for future software developers.

This guide is meant to serve as a learning tool for people who are just starting to learn Javascript. Please read from the official React website for further detail. Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Resources

A Beginner’s Guide to Javascript Operators and Conditional Statements

Jason Park — Thu, 29 Dec 2022 22:38:36 +0000

Introduction
Relational operators
Logical operators
Conditional operators
Conditional statements
- if, else if, else statements
- switch statements
Conclusion
Resources

Introduction

Whether you are a seasoned professional or just starting your journey as a software engineer, one of the first major concepts you will learn is conditional statements. Conditional statements are blocks of code that allow you to be able to control certain actions. Simply put, it helps your program make decisions based on certain information. Every conditional statement contains one or more tests, typically involving the use of relational and logical operators. Before diving into how conditional statements work, we must first understand the relevant relational and logical operators that compose these statements.

This guide is for those who are just getting started with Javascript. If you are still confused after reading this guide, please read more about these topics in detail at the MDN website. All links are listed in the Resources section.

Relational operators

Relational operators compare two values and return either true or false based on the operator. All of these require two variables, each on opposite sides of the operator. Below is a table of the relational operators.

Operator	Name	Use	Example
`>`	Greater than	Returns `true` if first value is greater than second value	1 > 3 // false
`<`	Less than	Returns `true` if first value is less than second value	1 < 3 // true
`>=`	Greater than or equal to	Returns `true` if first value is greater than or equal to second value	3 >= 3 // true
`<=`	Less than or equal to	Returns `true` if first value is less than or equal to second value	5 <= 3 // false
`===`	Strict equality	Returns `true` if both values equal each other (no type conversion)	‘hello’ === ‘hello’ // true
`!==`	Strict inequality	Returns `true` if both values do not equal each other (no type conversion)	‘3’ !== ‘3’ // false
`==`	Loose equality	Returns `true` if both values equal each other after type conversion	3 == ‘3’ // true
`!=`	Loose inequality	Returns `true` if both values do not equal each other after type conversion	3 != true // false

Table 1: Relational Operators

The difference between the strict and loose operators is that the strict operators will only return true if the two values are equal to each other without any type conversions. On the other hand, the loose operator attempts to convert the values into the same type before making the comparison. Since the behind-the-scenes conversion creates more room for errors and bugs, it is best practice to use the strict operators as default over the loose operators.

If you get to a point where you need to check between two values of different types, I recommend converting them into the same type yourself before using the strict operator to compare. It is important to also note that comparing values of different data types using relational operators may yield unpredictable results. This is yet another reason to make sure that the two values being compared are of the same data type before comparison.

Logical operators

Logical operators can be broken down into two types: unary (one variable) and binary (two variables). The unary operator has one variable to the right of ! and the binary operators have a variable on both sides of the operator. Below is a table of the logical operators.

Operator	Name	Use	Example
`!` (unary)	Not (or Bang)	Returns the opposite boolean	!3 // false
`&&` (binary)	And	Returns the first value if it is falsy; otherwise return the second value	0 && false // 0
`\|\|` (binary)	Or	Returns the first value if it is truthy; otherwise return the second value	undefined \|\| ‘hello’ // ‘hello’

Table 2: Logical Operators

! converts the value into a boolean (if it isn’t one already) and returns the opposite boolean value. Remember that all values are truthy except for:

false
undefined
null
NaN
0
“” or ‘’

In addition to its uses shown on the table, all three logical operators can be combined inside conditional statements to produce more elaborate tests. This will be shown in more detail in the following sections.

Conditional operators

A conditional operator returns one of two operands depending on the result of the conditional test. Another name for this is the ternary operator (or ternary expression).

Operator	Name	Use	Example
condition ? ifTrue : ifFalse	Ternary	Returns `ifTrue` if `condition` is `true`; otherwise return `ifFalse`	let x = 1 x > 0 ? x + 3 : x // 4

Table 3: The Conditional Operator

The ternary operator works the same as a simple if and else statement. So if we can just use if and else statements to accomplish what the ternary operator can do, why bother with it? The answer is conciseness. Traditional if and else statements will take up more lines than ternary expressions and for that reason, some may opt for this shorthand version in certain cases.

Conditional statements

Conditional statements combine the relational and logical operators to create a conditional test. Similar to the basic conditional operator, the conditional statement helps manage the flow of certain actions.

if, else if, else statements

As the heart of Javascript conditionals, the if statement is a versatile tool that helps developers control a certain conditional behavior. When combined with else if and else, it can cover most, if not all, conditional situations. The set-up for these statements are specified below.

if(condition1) {
  // execute if condition1 is true
} else if(condition2) {
  // execute if condition1 is false and condition2 is true
} else {
  // execute if previous tests are false
}

In the code block above, we have one if, else if and else statement. This suggests that there are three possible outcomes: condition1, condition2 and none of the above. You can add as many else if statements after the if and before the else if there are more outcomes. The else if and else statements are optional but in order to use them, you need an if statement in the beginning.

I mentioned earlier that && and || can increase the complexity of conditional statements. This is done by combining one or more conditional tests to generate a single multi-step test. We will start with the and operator, &&.

As its name implies, the and operator is used as a two part test. In order to pass the overall test, one must pass both individual conditions. If any one of the two conditions fail, the overall test will also fail.

const x = 5;

if(x > 0 && x < 3) {
  // code1
} else if(x > 5 && x <= 10) {
  // code2
}

The first condition tests if x is greater than 0 and if x is less than 3. If these conditions are fulfilled, we execute code1 in the first if statement. If not, we move on to the next conditional test. This one checks if x is greater than 5 and less than or equal to 10. Since x = 5, it doesn’t pass either conditions and neither code1 or code2 is executed.

We can think of || in a similar way but with the word “or” instead of “and.” There are two conditions and if one or the other passes, the entire condition passes.

const x = 3;

if(!x || x !== ‘hello’) {
  // code1
}

If !x equals true or x does not strictly equal ’hello’, we run code1. In any other case, we run code2 inside the else block. Since x equals 3, !x (or !3) equals false (all numbers are truthy and ! switches the truthiness of the variable). Moreover, x does not equal ’hello’, as it is assigned to 3. Because one of the two conditions results in true, we pass our overall test and code1 is executed.

switch statements

A switch statement contains an expression that is matched against each case value via strict equality. One at a time, it goes down each case until it finds a match. Once it does, it starts the execution from that case. If there isn’t a break keyword, the execution falls through and runs the block of code inside the next case, even if the case value doesn’t match. This process repeats until it meets break or checks every succeeding clause. The syntax is as follows:

switch(expression) {
  case value1:
    // execute if expression matches value1
  case value2:
    // execute if expression matches value2
    break
  default:
    // execute if expression doesn’t match value1 or value2
}

The break and default keywords are optional: the point of break is to cease the automatic fall through and immediately stop; default is there so it runs when there is no other match or when the execution reaches it from falling through.

const x = 3

switch(x + 1) {
  case 3:
    // code1
  case 4:
    // code2
  case 5:
    // code3
    break
  default:
    // code4
}

We start with x equals 3. The switch expression is x + 1, which equals 4. Starting from the top, there is no match until it reaches case 4. It proceeds to run code2 then falls through to case 5. Even though this isn’t a match, code3 is executed. The break at the end of case 5 stops the execution from falling through to default.

switch statements are more situational than if statements. They are most commonly utilized when there are many else if or else statements that need to be matched through strict equality (===).

Conclusion

In the preceding sections, we discussed the role of relational and logical operators within the context of conditional statements. After reviewing all the pertinent operators, we explored how if, else if, else and switch can cover almost every conditional test with the right combination of operators and statements.

It is an understatement to make the claim that conditional statements are important in programming. Even beyond the scope of software development, it plays a crucial role in our everyday lives. “I will go on a walk if it doesn’t rain” or “if I plan on going out tomorrow night, I will do my homework tonight” are some real life examples of conditional statements that we set for ourselves, sometimes without even thinking about them. With this in mind, it is paramount that novice software developers have a solid grasp on this concept before trekking forward in their new and exciting career.

This guide is meant to serve as a learning tool for people who are just starting to learn Javascript (and coding in general as these concepts apply to other languages beyond Javascript). Thank you for reading and if you have any questions or concerns about some of the material mentioned in this guide, please do not hesitate to contact me at jjpark987@gmail.com.

Forem: Jason Park

Building a Gym Logging App

Application Structure

Workout Tab

Schedule Tab

History Tab

Future Improvements

Repo Link

Resources

Building a Code Problem Solving Assistant

Workflow

Application Structure

LLM

Backend

Frontend

Docker Compose

Repo Links

Resources

Building a Lightweight OCR-Powered Receipt Parser

Requirements

App Structure

main.py

process_data.py

Running the App via Automator

Resources

A Beginner's Guide to Open Source Contributions on GitHub

Contents

Introduction

Preparation

Ways to Contribute

Raise an issue or make a suggestion

Reproduce a reported bug

Test a pull request

Solve a reported bug

General Guide

Summary

Resources

A Beginner’s Guide to App Deployment via PaaS Provider

Contents

Introduction

Basics

Deployment method

App preparation

Deploying

Backing and restoring the production database

Conclusion

Resources

A Beginner's Guide to Redux

Contents

Introduction

Basics

Implementing with React

File Organization

Conclusion

Resources

A Beginner’s Guide to Authentication and Authorization in Rails

Contents

Introduction

Authentication vs. Authorization

Cookies and Sessions

BCrypt

Signing Up

Logging In

Auto Login

Logging Out

Authorizing

Conclusion

Resources

A Beginner's Guide to Active Record

Contents

Introduction

Basics

Getting started with Active Record

Set up Gemfile

Create models and associations

Create new migrations

Migrate changes and check status

Next steps

Conclusion

Resources