DEV Community: Kai's brain dump

A CSS font styling protip for mixed English & Asian language sites

Kai's brain dump — Sun, 23 Jul 2023 15:46:48 +0000

Imagine you have a website that uses both English and Asian languages like Chinese, Japanese, or Korean. You want the English text to appear in a Western-style font and the Asian text in an appropriate Asian font.

To achieve this, you don't need to complicate things by separating the Asian text and writing special CSS rules for it. Instead, you can handle it simply by adding the Asian font as a fallback in your CSS file like this:

.content { font-family: <Western font>, <CJK font>; }

When someone opens your website in their browser, it will first try to display all the text using the primary Western font. However, since Western fonts can't show non-Latin characters, the browser will automatically switch to the fallback Asian font, but only for the Asian text.

Pretty neat!

How to auto-refresh Realm inside Android WorkManager

Kai's brain dump — Sun, 20 Mar 2022 17:57:25 +0000

The problem with Realm and background threads

Realm’s live objects only work when your Realm instance is operating from a Looper thread, namely your Activity and Fragment classes (the UI thread). However, typical use cases of Realm may require access from background threads too, and those instances won’t be auto refreshed, creating memory leak and large file size problems.

How to use Realm in a WorkManager background thread

I have used the following technique to obtain auto-refreshing Realm instances within WorkManager workers. Using a combination of Handler::post + suspendCoroutine + CoroutineWorker, I am able to achieve synchronous access to a Realm instance and ensure my Realm objects insider a WorkManager worker remain as live objects:

Full source code

import android.content.Context
import android.os.Handler
import android.os.HandlerThread
import androidx.work.CoroutineWorker
import androidx.work.WorkerParameters
import io.realm.Realm
import kotlin.coroutines.resume
import kotlin.coroutines.resumeWithException
import kotlin.coroutines.suspendCoroutine
import kotlinx.coroutines.Dispatchers
import kotlinx.coroutines.withContext

abstract class RealmCoroutineWorker(
    name: String,
    context: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(context, workerParams) {

  private val realmThread = RealmHandlerThread(name)

  abstract fun doWork(realm: Realm): Result

  final override suspend fun doWork(): Result {
    return withContext(Dispatchers.IO) {
      try {
        realmThread.startAndWaitUntilReady()
        realmThread.executeWithRealm { realm -> doWork(realm) }
      } catch (err: Exception) {
        Result.failure()
      } finally {
        realmThread.quit()
      }
    }
  }
}

class RealmHandlerThread(name: String) : HandlerThread(name) {
  @Volatile private var handler: Handler? = null
  @Volatile private var realm: Realm? = null

  fun startAndWaitUntilReady() {
    start()
    // HandlerThread's getLooper() blocks until it has a value
    handler = Handler(looper)
    handler?.post { realm = Realm.getDefaultInstance() }
  }

  suspend fun <T> executeWithRealm(realmFun: (Realm) -> T): T {
    return suspendCoroutine { continuation ->
      handler!!.post {
        try {
          continuation.resume(realmFun(realm!!))
        } catch (err: Exception) {
          continuation.resumeWithException(err)
        }
      }
    }
  }

  private fun beforeQuit(onFinished: () -> Any): Boolean {
    if (looper == null) {
      return false
    }
    handler?.post {
      realm?.close()
      onFinished()
    }
    return true
  }

  override fun quit(): Boolean {
    return beforeQuit { super.quit() }
  }

  override fun quitSafely(): Boolean {
    return beforeQuit { super.quitSafely() }
  }
}

Code explanation

Create a companion HandlerThread and attach a Looper and a Handler to it. Let’s call this class RealmHandlerThread. Create a Realm instance on this Looper thread.

class RealmHandlerThread(name: String) : HandlerThread(name) {
  @Volatile private var handler: Handler? = null
  @Volatile private var realm: Realm? = null

  fun startAndWaitUntilReady() {
    start()
    // HandlerThread's getLooper() blocks until it has a value
    handler = Handler(looper)
    handler?.post { realm = Realm.getDefaultInstance() }
  }

  private fun beforeQuit(onFinished: () -> Any): Boolean {
    if (looper == null) {
      return false
    }
    handler?.post {
      realm?.close()
      onFinished()
    }
    return true
  }

  override fun quit(): Boolean {
    return beforeQuit { super.quit() }
  }

  override fun quitSafely(): Boolean {
    return beforeQuit { super.quitSafely() }
  }
}

Use your RealmHandlerThread‘s Handler::post to perform all your Realm operations exclusively. Since your Realm instance lives on a Looper thread, all its objects become live and auto-refreshing objects.

Handler::post is asynchronous, so to be able to use your Realm synchronously inside your WorkManager Worker code, bridge the async and sync worlds with a suspendCoroutine.

class RealmHandlerThread(name: String) : HandlerThread(name) {
  ...

  suspend fun <T> executeWithRealm(realmFun: (Realm) -> T): T {
    return suspendCoroutine { continuation ->
      handler!!.post {
        try {
          continuation.resume(realmFun(realm!!))
        } catch (err: Exception) {
          continuation.resumeWithException(err)
        }
      }
    }
  }
  ...
}

Finally, hook your RealmHandlerThread to a CoroutineWorker.

abstract class RealmCoroutineWorker(
    name: String,
    context: Context,
    workerParams: WorkerParameters
) : CoroutineWorker(context, workerParams) {

  private val realmThread = RealmHandlerThread(name)

  abstract fun doWork(realm: Realm): Result

  final override suspend fun doWork(): Result {
    return withContext(Dispatchers.IO) {
      try {
        realmThread.startAndWaitUntilReady()
        realmThread.executeWithRealm { realm -> doWork(realm) }
      } catch (err: Exception) {
        Result.failure()
      } finally {
        realmThread.quit()
      }
    }
  }
}

Extend RealmCoroutineWorker to get a WorkManager Worker that enjoys synchronous access to an auto-refreshing Realm instance.

Get Android's screen width and height

Kai's brain dump — Thu, 12 Aug 2021 18:42:02 +0000

Inside your Activity:

override fun onStart() {
    val size = Point()
    if (android.os.Build.VERSION.SDK_INT >= android.os.Build.VERSION_CODES.R) {
        requireContext().display!!.getRealSize(size)
    } else {
        val windowManager = requireContext().getSystemService(Context.WINDOW_SERVICE) as WindowManager
        windowManager.defaultDisplay.getRealSize(size)
    }
    size.x // Width
    size.y // Height
}

Nginx configuration pitfalls

Kai's brain dump — Thu, 12 Aug 2021 18:36:04 +0000

Non-obvious Nginx configuration mistakes that take tons of time to debug when things go south.

nginx add_header not working (part 1)

Having separate add_header directives for different HTTP headers in server and location blocks causes the headers defined in the server block to be dropped from the request response.

Source: There could be several add_header directives. These directives are inherited from the previous level if and only if there are no add_header directives defined on the current level. (http://nginx.org/en/docs/http/ngx_http_headers_module.html#add_header)

Make sure you copy your add_header directives to your location blocks.

nginx add_header not working (part 2)

By default, HTTP headers with underscores are dropped by Nginx. To fix this, set: underscores_in_headers off;

Unwanted request rebalancing

The ip_hash algorithm rebalances your requests if you remove servers or reorder servers in the upstream server list and reload your Nginx config.

Source: If one of the servers needs to be temporarily removed, it should be marked with the down parameter in order to preserve the current hashing of client IP addresses. (http://nginx.org/en/docs/http/ngx_http_upstream_module.html#ip_hash)

Don’t use hostnames in your Nginx upstream blocks

Hostnames in your upstream block are resolved only once on Nginx start/reload, they are not dynamically resolved.

If the hostnames can’t be resolved, Nginx will fail to start/reload.
If their IPs change, Nginx won’t notice the change until you reload.

For these reasons, always use IPs instead of hostnames in your upstream blocks.

server level return directives take precedence over location blocks

server {
    root /my/path;
    location /file.txt {
        try_files $uri =404;    
    }

    # ...1000 lines of Nginx config below...

    return 301 https://www.example.com$request_uri;
}

Code language: PHP (php)

If you request /file.txt you’ll get an HTTP 301. Instead, you should do:

server {
    root /my/path;
    location /file.txt {
        try_files $uri =404;
    }
    location / {
        return 301 https://www.example.com$request_uri;
    }
}

Code language: PHP (php)

Failed POSTs are retried on old versions of Nginx

If you use an old Nginx (<1.9.13), please upgrade it ASAP. Below this Nginx version, non-idempotent HTTP requests such as POSTs are retried when they fail. This is dangerous as it could lead to sensitive requests such as payment requests being sent more than once.

(If you liked this, you might enjoy A few tips about Nginx caching)

Nginx caching tips

Kai's brain dump — Sun, 20 Dec 2020 13:04:49 +0000

Performance tips

Put the cache on a dedicated SSD/NVME disk. On an HDD, the performance hit caused by constant read/writes to disk of the cache manager will dwarf any caching benefits.
Don’t cache HTTP responses upon first hit. Use proxy_cache_min_uses 2; to only cache items that have been accessed more than once. This way, you will alleviate the proxy cache’s write pressure and prevent your cache from filling up with content that’s seldom accessed.
Avoid unexpected backend traffic spikes caused by cache misses:
- Set proxy_cache_lock on;
  - When there is a cache miss and multiple simultaneous requests hit the same URL, send a single request to your backend while the rest of the requests wait on the Nginx side.
- Add proxy_cache_use_stale updating; to your Nginx config.
  - This flag instructs Nginx to keep serving stale cache content to users while the cache is being refreshed.
Save bandwidth by refreshing your Nginx cache with conditional GET requests, set proxy_cache_revalidate on;
Cold start blues: when you cold start an Nginx instance with a big existing cache on disk, wait a few minutes before you expose it to the public. Nginx needs to scan the entire cache to load its metadata into memory.

Nginx proxy cache for Tomcat servers

Java web apps running on Apache Tomcat always set a JSESSIONID cookie in the HTTP response, even if your web visitor is not logged into any account. To prevent session IDs from leaking into your Nginx cache, you need to filter out any Set-Cookie response headers returned by your backend.

proxy_ignore_headers Set-Cookie;
proxy_hide_header Set-Cookie;

How to bypass the cache for dynamic content and logged-in users

Your backend should set a nocache cookie in the HTTP responses for dynamic content. Then you include proxy_cache_bypass $cookie_nocache; in your Nginx configuration to bypass your Nginx cache for those requests.

Nginx proxy cache for multilingual sites: use this cache key

The default Nginx caching key doesn’t work well with sites with multiple subdomains. You can customize your cache key by setting proxy_cache_key. This one has worked well for me:

proxy_cache_key $scheme$host$uri$is_args$args;

How to purge cache items

If your Nginx runs on a Debian server, I highly recommend you install the nginx-extras package from the Debian repos, instead of the nginx package from the official repos. The nginx-extras package comes with the ngx_cache_purge community module, whereas the nginx package from the official repos doesn’t.

(If you liked this, you might enjoy 6 Nginx configuration pitfalls that bit me in the ass)