Skip to content

Instantly share code, notes, and snippets.

View joeywang's full-sized avatar

Joey Wang joeywang

  • reallyenglish.com
  • London
View GitHub Profile
  1. popup custom window rendered
  2. talk to the endpoint to sign in again.

another solution

  1. iframe to load login page
  2. detect sign or not by comparing the href of the page.

popup a window to ask to reload the page.

# file: config/initializers/connection_validation_test.rb
# This block will be executed only after Active Record has finished loading.
ActiveSupport.on_load(:active_record) do
  # Within this block, it's now safe to modify Active Record components.
  module ActiveRecord
    module ConnectionAdapters
      # It's good practice to check if the class is defined to avoid errors
      # in environments where it might not be (e.g., if you switched to MySQL).
      if defined?(ActiveRecord::ConnectionAdapters::PostgreSQLAdapter)

The Mystery of the Premature 502: Untangling GCP's Two Health Check Systems

The Scene of the Crime: A Flawless Deployment Ends in a 502

You’ve just deployed a new version of your application to Google Kubernetes Engine (GKE). The CI/CD pipeline glows green, kubectl get pods shows all pods in a Running state, and your deployment is, by all accounts, successful. You navigate to your application's URL, hit refresh, and are greeted by the dreaded 502 Bad Gateway error.

After a few frantic refreshes, the error vanishes and your application loads perfectly. What just happened? You have readiness probes configured. They should have prevented traffic from reaching the pods before they were ready. Yet, somehow, traffic arrived too early.

This is the story of a common and confusing problem in GKE, born from a simple fact: there aren't one, but two separate health check systems at play. Understanding the division between them is the key to solving the mystery of the premature 502.

The Art of the Vanishing Form: Taming Temporary Data in Rails Wizards

Multi-step forms, or "wizards," are a common pattern for guiding users through complex data entry processes like registrations, profile setups, or product configurations. A key challenge in designing these is managing the data collected at each step before the user finally hits that "Submit" button. Where does this transient information live? How do we ensure a smooth user experience without cluttering our database with incomplete records?

One principle should guide us: Don't pollute your primary database with inconsistent, temporary data if you can avoid it. The overhead of storing and then cleaning up these partial records is often more trouble than it's worth. Thankfully, Ruby on Rails offers elegant ways to handle this "in-flight" data, leveraging its powerful object model and session management capabilities.

Let's explore the common strategies and figure out the best path.

The Core Problem: Data in Limbo

# --- CONNECTION POOLING ---
num_init_children = 50
max_pool = 1
child_life_time = 300
child_max_connections = 1000
connection_life_time = 0
# --- LOAD BALANCING ---
load_balance_mode = on
# Assuming backend0 is primary, backend1 is replica

Got it! Since the worker.js file is inside the assets directory of an Android project, you will need to load it from there and inject it into the WebView. Unfortunately, the WebView itself doesn't provide direct access to files in the assets folder via standard file paths, but you can work around this limitation by reading the file as a string and then injecting it into the WebView.

Here’s how you can load the worker.js file from the assets folder, read its content, and inject it into a WebView dynamically as a JavaScript Blob.

Step-by-Step Approach:

  1. Read the worker.js File from the Assets Folder Use Android's AssetManager to read the contents of worker.js from the assets folder.

  2. Inject the Script into the WebView

@joeywang
joeywang / Deep Dive into Ruby Internals: From Rails Caching to C-Level Object IDs.md
Created October 27, 2024 11:29
Deep Dive into Ruby Internals: From Rails Caching to C-Level Object IDs

Deep Dive into Ruby Internals: From Rails Caching to C-Level Object IDs

When debugging Rails applications, sometimes we stumble upon fascinating aspects of Ruby's internal workings. This article shares a journey that started with a simple Rails caching issue and led us deep into Ruby's object model and memory management system.

The Starting Point: Rails Caching and Kaminari

It all began with what seemed like a straightforward Rails caching operation:

Rails.cache.write(Lesson.page(1))
@joeywang
joeywang / Understanding and Debugging Anonymous Modules in Ruby: A Deep Dive with Kaminari.md
Created October 27, 2024 00:38
Understanding and Debugging Anonymous Modules in Ruby: A Deep Dive with Kaminari

Understanding and Debugging Anonymous Modules in Ruby: A Deep Dive with Kaminari

When working with Rails caching, you might encounter the cryptic error: TypeError: can't dump anonymous module. This article explores what anonymous modules are, why they can't be serialized, and how to debug these issues using Kaminari as a real-world example.

Table of Contents

  1. Understanding Anonymous Modules
  2. Why Anonymous Modules Can't Be Serialized
  3. The Kaminari Case Study
  4. Debugging Techniques
  5. Solutions and Best Practices
@joeywang
joeywang / Creating Practical Kubernetes Shell Aliases and Functions: A Developer's Guide.md
Created October 26, 2024 21:30
Creating Practical Kubernetes Shell Aliases and Functions: A Developer's Guide

Creating Practical Kubernetes Shell Aliases and Functions: A Developer's Guide

Introduction

When working with Kubernetes, developers often find themselves typing the same commands repeatedly. While kubectl is a powerful tool, its verbosity can slow down common workflows. This guide will explore practical aliases and functions to streamline your Kubernetes development experience, with a focus on container access patterns.

Basic Kubectl Aliases

Let's start with some fundamental aliases that form the building blocks of more complex functions:

Migrating from Kaminari to will_paginate in Rails: A Complete Guide

Pagination is a crucial feature in web applications, helping manage large datasets by breaking them into manageable chunks. While both Kaminari and will_paginate are excellent pagination libraries for Rails, you might find yourself needing to migrate from one to the other. This guide walks through the complete process of migrating from Kaminari to will_paginate, covering all aspects from basic setup to handling complex scenarios.

Table of Contents

  1. Basic Setup
  2. Model Changes
  3. Controller Updates
  4. View Modifications
  5. API Response Adjustments