Shots

Recently I just completed Ruby2->Ruby3 + Rails6->Rails7 upgrade for my private project. Initially I thought it would take a lot of fixing to make it work, but was surprised it only impacted 17 out of the 88 Ruby files out of the app/ directory. Since it was a relatively simple fix, I decided to just write a shot instead of a long article to document my changes.

I have 27 gems before the upgrade. In order to use Rails7, I had to deprecate webpacker and add the replacement gems:

gem 'sassc-rails', '~> 2.0'
gem 'jsbundling-rails', '~> 1.0'
gem 'cssbundling-rails'
gem 'sass-embedded'
gem 'sprockets', '~> 4.0'

This also removed a few JS packages related to webpacker:

"@rails/webpacker": "5.4.3",
"webpack-dev-server": "^4.9.2"

While adding new ones to replace the missing webpacker package:

"@babel/core": "^7.22.10",
"@babel/plugin-proposal-class-properties": "^7.18.6",
"@babel/plugin-proposal-object-rest-spread": "^7.20.7",
"@babel/plugin-syntax-dynamic-import": "^7.8.3",
"@babel/plugin-transform-destructuring": "^7.22.10",
"@babel/plugin-transform-regenerator": "^7.22.10",
"@babel/plugin-transform-runtime": "^7.22.10",
"@babel/preset-env": "^7.22.10",
"babel-loader": "^9.1.3",
"babel-plugin-macros": "^3.1.0",
"css-loader": "^6.8.1",
"vue-style-loader": "^4.1.3",
"webpack": "^5.88.2",
"webpack-cli": "^5.1.4"

Then, I added a new webpack config file in order to compile my Vue2 assets:

const path    = require("path")
const webpack = require("webpack")
const { VueLoaderPlugin } = require("vue-loader")
const mode = process.env.NODE_ENV === 'development' ? 'development' : 'production'

// Reference: https://vue-loader.vuejs.org/guide/#vue-cli
module.exports = {
  mode,
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: "vue-loader"
      },
      {
        test: /\.js$/,
        exclude: /node_modules/,
        loader: 'babel-loader'
      },
      {
        test: /\.css$/,
        use: [
          'vue-style-loader',
          'css-loader'
        ]
      }
    ]
  },
  entry: {
    application: "./app/javascript/application.js",
    index: "./app/javascript/packs/dashboard/index.js"
  },
  output: {
    filename: "[name].js",
    sourceMapFilename: "[file].map",
    path: path.resolve(__dirname, "..", "..", "app/assets/builds"),
  },
  plugins: [
    new webpack.optimize.LimitChunkCountPlugin({
      maxChunks: 1
    }),
    new VueLoaderPlugin()
  ],
  optimization: {
    moduleIds: "deterministic"
  }
}
 

Finally, I added new scripts in package.json to allow me to build my assets:

"scripts": {
  "build": "webpack --config config/webpack/webpack.config.js",
  "build:css": "sass ./app/assets/stylesheets/application.scss:./app/assets/builds/application.css --no-source-map --load-path=node_modules"
}

That’s about all the configuration changes for the Rails7 upgrade.

Next there’re some syntax and API changes due to Ruby3 and Rails7. The list is non-exhaustive, because I might not have used many features that are impacted by the upgrade. I also omitted the ones where there’s deprecation warning and documented fix for it.

Serializable hash

Previously, I could use ActiveRecord#serializable_hash without any arguments and it will serialize additional instance methods in the AR. For example, I have a User with a #avatar method:

class User < ApplicationRecord
  def avatar
    "http://www.gravatar.com/avatar/#{Digest::MD5.hexdigest(email)}?s=30"
  end
end

I used to be able to serialize by invoking user.serializable_hash. In Rails7, I had to explicitly pass in the methods argument: user.serializable_hash(methods: %i(avatar)).

CSRF token verification

Previously, these lines of code worked.

protect_from_forgery with: :exception, unless: -> { request.format.json? }

before_action :authenticate_user!

In Rails7, I have to add the prepend: true argument to protect_from_forgery, so that it will prepend this method to the before_action chain.

The thing I haven’t figured out is why it didn’t work without prepend: true, even though I have declared protect_from_forgery before authenticate_user!.

This is the Github README of the devise gem explaining the problem above.

That’s about all the changes I had to make. I’m still observing if anything else is broken, if there’s something new, I will update this post again. Happy upgrading!

I needed to build a bi-directional indefinite progress bar for the Triple Tee App.

I found some tutorial on how to build a static uni-directional one on W3 Schools, so I improvised and tried to built one that is bi-directional and runs indefinitely like this:

(This progress bar is running in real-time, click here to stop the bar)

The idea I had was to use 2 <div>s, 1 growing towards the right side, and the other growing towards the left side. Let’s call them the forward-bar and reverse-bar respectively.

<div id="progress-bar" class="progress-bar">
  <div id="forward-bar" class="bar forward-bar" style="width: 0%;">
  </div>
  <div id="reverse-bar" class="bar reverse-bar" style="width: 100%;">
  </div>
</div>

At the initial state, the forward-bar will have 0% width and colored, while the reverse-bar will have 100% width but not colored:

.progress-bar {
  display: flex;
  width: 400px;
  background-color: #f4e3d7;
}

.bar {
  height: 10px;
}

.forward-bar {
  background-color: #502d16;
}

.reverse-bar {
  background-color: #ffffff;
}

Then, when the forward-bar grows to 100% width, I append the .reverse class to the progress-bar container, so that I can use it to style the forward-bar and reverse-bar in reverse colors:

.progress-bar.reverse .forward-bar  {
  background-color: #ffffff;
}

.progress-bar.reverse .reverse-bar {
  background-color: #502d16;
}

In order to determine the current direction, I created a variable named direction and initialised it to forward. We could also use a boolean forward and set to true, but I prefer to use string for clarity here.

let direction = 'forward'

Then I need to know what’s the current width of the bars, so I created a function for that:

function getWidth(bar) {
  return parseInt(bar.style.width.split('%')[0])
}

Once I know the width, I can grow or shrink the bar by adding steps to the width:

function step(bar, direction, current) {
  if (direction === 'forward') {
    bar.style.width = [(current + 5).toString(), '%'].join('')
  } else {
    bar.style.width = [(current - 5).toString(), '%'].join('')
  }
}

When I step forward, I grow the width of the forward-bar while shrinking the width of the reverse-bar. In the other direction, I reverse the action on the bars accordingly:

const forwardBar = document.getElementById('forward-bar')
const reverseBar = document.getElementById('reverse-bar')

function stepForward() {
  const forwardWidth = getWidth(forwardBar)
  const reverseWidth = getWidth(reverseBar)

  step(forwardBar, 'forward', forwardWidth)
  step(reverseBar, 'reverse', reverseWidth)
}

function stepBackward() {
  const forwardWidth = getWidth(forwardBar)
  const reverseWidth = getWidth(reverseBar)

  step(forwardBar, 'reverse', forwardWidth)
  step(reverseBar, 'forward', reverseWidth)
}

If the bar grows to the full 100% width, I will need to change the direction. This is also where I add the .reverse class to the progress-bar so that it will update the background color of individual bars:

const progressBar = document.getElementById('progress-bar')

function changeDirection() {
  if (direction === 'forward') {
    direction = 'reverse'
    progressBar.classList.add('reverse')
  } else {
    direction = 'forward'
    progressBar.classList.remove('reverse')
  }
}

Now we can put it all together in animation using the setInterval function, so that it will grow/shrink the bar every 10ms, creating the effect that it is moving:

const intervalId = setInterval(animate, 10)

function animate() {
  const forwardWidth = getWidth(forwardBar)
  const reverseWidth = getWidth(reverseBar)

  if (direction === 'forward' && forwardWidth === 100) {
    changeDirection()
    stepForward()
  } else if (direction === 'reverse' && reverseWidth === 100) {
    changeDirection()
    stepBackward()
  } else if (direction === 'forward') {
    stepForward()
  } else if (direction === 'reverse') {
    stepBackward()
  }
}

That’s it! Hope this has been useful.

I released the installer for MacOS (arm64) distribution for the SG SSB Tracker app on Github Releases, and downloaded it to install the app, MacOS told me it’s damaged and should move it to the bin.

I tried installing the app locally from the installer packaged by Electron Forge, the app can open just fine.

After some search, I stumbled upon this thread on MarkText Github Issues. It seems like the issue is due to the app not being code signed, and so Apple blocked it from being opened? The only workaround is to remove the app from “Quarantine”, by running this command:

xattr -r -d com.apple.quarantine /Applications/SG\ SSB\ Tracker.app

A quick look at the xattr man page explains what the command is actually doing:

• xattr is the command used to display or manipulate extended attributes of a file.
• -r applies the command recursively to the file.
• -d deletes a given attribute of the file.
• com.apple.quarantine is the attribute that puts the app in “Quarantine”.

On the other hand, if I build the app for x64 distribution, I can open the app on a arm64 Mac, this time it will still try to block me, but at least it allows me to “Open Anyway”.

Does that mean I have to pay USD99/year just to be able to sign a free app for distribution to Apple Silicon Mac users?

So the problem I encountered was this: I have a page that have 2 separate grid sections. Each section can have its own variable number of items. I want to display the items in a 3-column grid layout.

My first solution was taken from the web, and it’s something along this line.

.container {
  display: grid;
  grid-template-columns: auto auto auto;
  justify-content: center;
  align-items: center;
}

But it turned out like this when I have 2 items in the second section:

Due to the auto value for grid-template-columns, when there’re only 2 items, it will stretch and fit the width of the container.

So I thought I had to use math to calculate the width of each grid column, in order for the 2-item grid to only take up exactly 2 column-width.

// 8rem = 1rem on each side of the grid for 3 grids + container padding of 1rem on each side
.container {
  display: grid;
  grid-template-columns: calc((100vw - 8rem) / 3) calc((100vw - 8rem) / 3) calc((100vw - 8rem) / 3);
  justify-content: center;
  align-items: center;
}

It’s what I wanted, but there’s too much math going on.

Okay, then I read about this thing called fractional units (fr), so I thought what about I change to this:

.container {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
  justify-content: center;
  align-items: center;
}

Now this looks exactly like the previous one, without the complex calculation.

I drank a few cups of coffee to figure this out so you don’t have to. Enjoy this mid-day shot.

While building the SG Bank Interests Compare App, I faced a problem: “How can I serve JSON data API while hosting the app on Github Pages?”

I forgot how I stumbled upon the idea, but eventually I decided to make use of Github itself as a pseudo-API server. Here’s how I executed it for my app.

But first, let’s talk a little bit about why Github is actually a pretty good candidate:

• Versioning is built into it, thanks to git commits.
• Github can serve raw files under the https://raw.githubusercontent.com/ domain.

It’s screaming at me that: “Hey, I can actually be a pretty good versioned data API server!”

So I separated my app into 2 repositories:

• sg_bank_int_compare-source: This will host the source code, data files and build scripts.
• sg_bank_int_compare: This will host the built page that can be served by Github Pages.

For the sg_bank_int_compare-source repo, I have both the page assets and the data JSON files.

Note: Omitted some files for clarity.

src
├── App.vue
├── components
│   └── CalculatorForm.vue
├── data
│   ├── cimb_fast_saver.json
│   └── uob_one.json
├── main.js
└── scripts
    └── calculator.js

Then in the sg_bank_int_compare repo, I further separate it into 2 branches:

• main: This is where the app index page and assets will be served.
• data: This only contains the JSON data files.

Whenever I make changes to the source, I will run a script that will checkout the data branch in sg_bank_int_compare, then copy the data/*.json files into the data directory. If there are changes to the data, it will create a new commit.

The script then reads this commit hash, and compare it with the current LATEST_VERSION in the source file. If it’s different, then it will replace it with the new commit hash.

And finally, the script will build the page and checkout the main branch in sg_bank_int_compare to create a commit.

Now when I push the data branch to Github, I will be able to see the raw JSON files under https://raw.githubusercontent.com/coffeebrewapps/sg_bank_int_compare/${LATEST_VERSION}/data/. And then I push the main branch to Github, and it will be able to request for the JSON data from the same URL.

// source will be something like:
// https://raw.githubusercontent.com/coffeebrewapps/sg_bank_int_compare/366b5c954e2c5155b9c9f9c728a9b428956917e2/data/cimb_fast_saver.json
axios.get(source)
  .then(function (response) {
    // parse the response and use the data for interest calculation
  })
  .catch(function (error) {
  });

So, after reading so far, you might be thinking: “Why not just hardcode the data in a variable in JS and read directly?”

Yes, I did think about that question too, but I wanted to have a separation of “client” and “server”, so that in the future, if I do have the resource to host the data on an actual server, I don’t have to change a lot of my client code, and just have to update the API URLs.

I hope this little trick is useful for you too if you intend to build an app hosted on Github Pages that requires a data API but don’t have an actual server to serve it.