Skip to main content
📜Heads up!
  • I wrote this post more than 2 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead
📜Heads up!
  • I wrote this post more than 2 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead

counting...

The only thing I missed about my Windows computer was locking the screen since I was so used to locking my computer with ⊞Win+L. Mac offered an alternative called the Hot Corner. But it never was so intuitive and fast as pressing ⊞Win+L. However, Mac now supports locking the computer by pressing ⌘Command+L from macOS Mojave.

How do I do it?

  1. Go to System Preferences.

Go to System Preferences.

Go to System Preferences.
  1. Go to Keyboard → Shortcuts → App Shortcuts and press + at the bottom.

Keyboard → Shortcuts → App Shortcuts

Keyboard → Shortcuts → App Shortcuts
  1. On your Menu Bar, press the  Apple Logo. Check the name of ^Control+⌘Command+Q. It is responsible for locking your Mac. Remember the name of the menu.

Menu Bar

Menu Bar
  1. Go back to the Preference app. Select All Applications at Application Setting. Next, enter the Menu Title you have just checked. This title will vary according to your macOS Language Preference. Finally, enter ⌘Command+L at Keyboard Shortcut. You can enter it here if you want to lock your Mac with Keyboard Shortcut other than ⌘Command+L. Press Add if you are finished.

All Applications

All Applications
  1. Now you can see that the same Lock Screen option at your menu bar will show the Keyboard Shortcut you just changed.

Menu Bar After

Menu Bar After

This method works in almost every case. Sometimes, the app will have ⌘Command+L as its Keyboard Shortcut. One example is the System Preferences app that uses the ⌘Command+L as going to the Lobby of System Preferences. I have never seen any other cases where ⌘Command+L doesn't work as expected.

  • If some app uses ⌘Command+L as their default shortcuts, you can set them to some other random shortcuts, clearing the path for the Lock Screen shortcut.

Shortcuts Setting

Shortcuts Setting
  • You can now click the Touch ID button from macOS Big Sur to lock your Mac.
📜Heads up!
  • I wrote this post more than 2 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead

counting...

I recently came across a Korean font called Spoqa Han Sans. It attracted me due to its simplicity and readability. However, I didn't like its English glyph (based on Noto Sans, which I didn't love to death.)

After a while, I figured out how to define a language range for each font. While importing a font face, we need to add unicode-range.

@font-face {
font-family: 'Spoqa Han Sans';
/* Omitted */
unicode-range: U+AC00-D7AF;
}

U+AC00-D7AFis the Unicode range of Korean glyphs.

Can't find @font-face?

We add either of the following statements to define a font in most cases.

<link
href="//spoqa.github.io/spoqa-han-sans/css/SpoqaHanSans-kr.css"
rel="stylesheet"
type="text/css"
/>
@import url(//spoqa.github.io/spoqa-han-sans/css/SpoqaHanSans-kr.css);

This way has the advantage that I do not need to care about updating the font. It automatically updates when the font is updated at the font server (Of course, this could also be a disadvantage in some cases). But we cannot define unicode-range in this case. So rather than importing the scripts like above, we could copy & paste the actual script itself. Access the URL provided in your @import statement with https: in front of it, and you will find the license of the font and its @font-face statements.

Copy this value and add them to your CSS, then define the unicode-range. Note that this method will not automatically update your font, but you can always recopy & repaste when the @font-face in your @font-face gets updated.

📜Heads up!
  • I wrote this post more than 2 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead

counting...

Ghost opens every external URL on the same page by default. This behavior distracts the user and increases the bounce rate. While it seems that there is no built-in option on Ghost to open external links in a new tab, we can fix this by injecting a short snippet of code.

<script>
var links = document.querySelectorAll('a');
for (var i = 0; i < links.length; i++) {
if (links[i].hostname != window.location.hostname) {
links[i].target = '_blank';
links[i].rel = 'noopener';
}
}
</script>

Paste this code at Ghost Settings → Code injection → Site Footer.

How it works

Contain every link in an array. For every link, if the link's hostname is different from this Ghost's hostname, change the target and rel values.

Changing the target to _blank will do the job. However, this will run the external link in the same Ghost process, leading to possible performance drops and security risks. We can prevent this by setting the rel value as noopener.

While modifying every link with JavaScript whenever accessing the page might slow down your Ghost, the performance impact will be ignorable unless the page has many external links. This trick will do its job until Ghost provides us a default option to open links in a new tab.

Additional readings

📜Heads up!
  • I wrote this post more than 2 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead
📜Heads up!
  • I wrote this post more than 2 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead

counting...

Hero Image. Building a payment system for school festivals

MinsaPay is a payment system that was built for the Minjok Summer Festival. It works like a prepaid tap-to-pay card. Every source and piece of anonymized transaction data is available on GitHub.

Stats

But why does a school festival need a payment system?

My high school, Korean Minjok Leadership Academy (KMLA), had a summer festival like any other school. Students opened booths to sell food and items they created. We also screened movies produced by our students and hosted dance clubs. The water party in the afternoon is one of the festival's oldest traditions.

Because there were a lot of products being sold, it was hard to use regular paper money (a subsequent analysis by the MinsaPay team confirmed that the total volume of payments reached more than $4,000). So our student council created proprietary money called the Minjok Festival Notes. The student council had a dedicated student department act as a bank to publish the notes and monitor the currency's flow. Also, the Minjok Festival Notes acted as festival memorabilia since each year's design was unique.

The Minjok Festival Note design for 2018 had photos of the KMLA student council members at the center of the bill. The yellow one was worth approximately $5.00, the green one was worth $1.00, and the red one was worth 50 cents.

The Minjok Festival Note design for 2018 had photos of the KMLA student council members at the center of the bill. The yellow one was worth approximately $5.00, the green one was worth $1.00, and the red one was worth 50 cents.

But there were problems. First, it was not eco-friendly. Thousands of notes were printed and disposed of annually for just a single day. It was a waste of resources. The water party mentioned above was problematic as well. The student council made Minjok Festival Notes out of nothing special, just ordinary paper. That made the notes extremely vulnerable to water, and students lost a lot of money after the water party. Eventually, the KMLA students sought a way to resolve all of these issues.

Idea

The student council first offered me the chance to develop a payment system. Because I had thought about the case beforehand, I thought it made a lot of sense. I instantly detailed the feasibility and possibilities of the payment system. But even after designing the system in such great detail that I could immediately jump into the development, I turned down the offer.

I believe in the social responsibilities of the developer. Developers should not be copy-pasters who meet the technical requirements and deliver the product. On the contrary, they are the people with enormous potential to open an entirely new horizon of the world by conversing with computers and other technological media. Therefore, developers have started to possess the decisive power to impact the daily lives of the rest of us, and it is their bound responsibility to use that power to enhance the world. That means developers should understand how impactful a single line of code can be.

Of course, I was tempted. But I had never done a project where security was the primary interest. It was a considerable risk to start with a project like this without any experience or knowledge in security. Many what-ifs flooded my brain. What if a single line of code makes the balance disappear? What if the payment record gets mixed up? What if the server is hacked? More realistically, what if the server goes down?

People praise audacity, but I prefer prudence. Bravery and arrogance are just one step apart. A financial system should be flawless (or as flawless as possible). It should both be functional and be performing resiliently under any condition. It didn't seem impossible. But it was too naïve to believe nothing would happen, as I was (and am still) a total newbie in security. So I turned it down.

Wait, payment system using Google Forms?

The student council still wanted to continue the project. I thought they would outsource the task to some outside organization. It sounded better since they would at least have some degree of security. But the council thought differently. They were making it themselves with Google Forms.

When I was designing the system, the primary issue was payment authorization. The passcode shouldn't be shared with the merchant, while the system could correctly authorize and process the order. The users can only use the deposited money in their accounts. This authorization should happen in real-time. But I couldn't think of a way to nail the real-time authorization with Google Forms. So I asked for more technical details from one student council member. The idea was as follows:

Abstract of a Google-Form-Powered Payment System
  • Create one Google Form per user. (We have about 400 users in total.)
  • Create QR codes with links to the Google Form. (So it's 400 QR codes in total.)
  • Create a wristband with the QR code, and distribute them to the users.
  • Show that wristband when purchasing something.
  • The merchant scans the QR code and opens the link in incognito mode.
  • Input the price and the name of the booth.
  • Confirm with the user (customer) and submit the response.
  • Close the incognito tab.

So the idea was to use the Google Form's unique address as a password. Since the merchants are supposed to use incognito mode, there should be a safety layer to protect the user's Google Form address (in theory). They will need to make a deferred payment after the festival. But as a developer, this approach had multiple problems:

Potential Problems I found
  • How are we going to manage all 400 Google Forms?
  • Intended or not, people will lose their wristbands. In that case, we will need to note the owner of the wristband in every Google form to calculate the spending. Can we deliver those QR codes to the correct owner if we do?
  • If the merchant doesn't use incognito mode, it will be hard for an ordinary person to tell the difference. If that happens, it is possible to attack the exposed Google form by submitting fake orders. We could also add a "password," but in that case, we cannot stop the customer from providing an incorrect password and claiming that they were hacked by someone else.
  • If the merchant has to select the booth and input the price manually, there will be occasions where they make a typo. Operators could fix a typo in the price value relatively quickly, but a typo or misselection in the booth value would be a pain since we would have to find out who made a mistake and the original order. Imagine there were 20 wrong booth values. How are we going to trace the real booth value? We could guess, but would that sort of record have its value as reliable data?
  • How are we going to make the deferred payment? How will we extract and merge all 400 of the Google Forms response sheets? Even worse, the day after the festival is a vacation. People care about losing money but not so much about paying their debts. There could be students who just won't come back. It would be excruciating to notify all those who didn't deliver. But if the money is prepaid, the solution is comparably easy. The council members could deposit the remaining balance to their phone number or bank account. We don't need to message dozens of students; we could do the work ourselves.
  • The student council will make the Google Form with the student council's Google account. That Google account will have restricted access, but a few students will be working together to create all 400 Google forms. Can we track who makes the rogue action if someone manipulates the Google form for their benefit?
  • Can this all be free from human error?

It could work in an ideal situation. But it will accompany a great deal of confusion and entail a noticeable discomfort on the festival day. That made me think that even though my idea had its risks, mine would still be better. So, I changed my mind.

Development

Fortunately, I met a friend with the same intent—our vision and idea about the project aligned. I explained my previous concept, and we talked to each other and co-developed the actual product. We also met at a cafe several times. I set up and managed the DNS and created the front-end side. Below are the things we thought about while making the product.

Details that my team considered
  • We won't be able to use any payment gateway or third-party payment service since we are not officially registered, and we will use it for a single day. Some students don't own smartphones, so we won't be able to use Toss or KakaoPay (Both are well-known P2P payment services in South Korea, just like Venmo). Therefore, there cannot be any devices on the client-side. We would need to install computers on the merchant's side.
  • It is impossible to build a completely automated system. Especially in dealing with cash, we would need some help from the student council and the Department of Finances and Information. Trusted members from the committee will manually count and deposit the money.
  • There must be no errors in at least the merchant and customer fields since they would be the most difficult errors to fix later. But, of course, we cannot expect that people will make no mistakes. So, instead, we need to engineer an environment where no one can make a mistake even if they want to.
  • The booths may be congested. If each customer needs to input their username and password every time, that will pose a severe inconvenience. For user experience, some sort of one-touch payment would be ideal.
  • For this, we could use the Campus ID card. Each card has a student number (of course) and a unique value for identifying students at the school front door. We could use the number as the username and the unique value as the password. Since this password is guaranteed to be different for each student, we would only need the password for identification purposes.
  • The final payment system would be a prepaid tap-to-pay card.
  • Developers would connect each account with its owner's student ID.
  • Students could withdraw the remaining money after the festival.

We disagreed on two problems.

  1. One was the platform. While my partner insisted on using Windows executable programs, I wanted the system to be multi-platform and asked to use web apps. (As you might expect, I use a Mac.)
  2. The other was the method of reading data from the Campus ID card. The card has an RFID chip and a bar code storing the same value. If we chose RFID values, we would have to purchase ten RFID readers, spending an additional $100. Initially, I insisted on using the embedded laptop webcam to scan the barcode because MinsaPay was a pilot experiment at that time. I thought that such an expense would make the entire system questionable in terms of cost-effectiveness. (I said "Wait, we need to spend an additional $100 even though we have no idea if the system will work?")

We chose web and RFID, conceding one for each. I agreed to use RFID after learning that using a camera to read bar codes wasn't that fast or efficient.

Main Home, Admin Page, and Balance Check Page of the product.

Main Home, Admin Page, and Balance Check Page of the product.

And it happened

Remember that one of the concerns was about the server going down?
On the festival day, senior students had to self-study at school. Then at one moment, I found my phone had several missed calls. The server went down. I rushed to the festival and sat in a corner, gasping and trying to find the reason. Finally, I realized the server was intact, but the database was not responding.
It was an absurd problem. (Well, no problem is absurd, per se, but we couldn't hide our disappointment after figuring out the reason.) We thought the free plan would be more than enough when we constructed our database. However, the payment requests surged and exceeded the database free tier. So we purchased a $9.99 plan, and the database went back to work. It was one of the most nerve-wracking events I ever had.

The moment of upgrading the database plan. $10 can cause such chaos!

The moment of upgrading the database plan. $10 can cause such chaos!

While the server was down, each booth made a spreadsheet and wrote down who needed to pay how much. Afterward, we settled the problem by opening a new booth for making deferred payments.

The payment log showed that the server went down right after 10:17:55 AM and returned at 10:31:10 AM. It was evident yet intriguing that the payments made per minute were around 10 to 30 before the crash but went down to almost zero right after restoring the server. If you are interested, please look here.

Due to exceeding the database free tier, the server went down for 13 minutes and 15 seconds after payment #1546.

Due to exceeding the database free tier, the server went down for 13 minutes and 15 seconds after payment #1546.

Results

1. MinsaPay

The entire codebase for MinsaPay is available on GitHub. First, though, I must mention that I still question the integrity of this system. One developer reported a security flaw that we managed to fix before launch. However, the system has unaddressed flaws; for example, though unlikely, merchants can still copy RFID values and forge ID cards.

2. Payment Data

I wanted to give students studying data analysis more relatable and exciting data. Also, I wanted to provide financial insights for students planning to run a booth the following year. Therefore, we made all payment data accessible.

However, a data privacy problem arose. So I wrote a short script to anonymize personal data. If a CSV file is provided, it will anonymize a selected column. Identical values will have the same anonymized value. You can review the anonymized data here.

Note for Developers

I strongly recommend thoroughly auditing the entire code or rewriting it if you use this system. MinsaPay is under the MIT license.

What I Learned

There is ample room for improvement.

First, there are codes with numerous compromises. For example, we made a lot of trade-offs not to miss the product deadline (the festival day). We also wanted to include safety features, such as canceling payments, but we didn't have time. More time and development experience would have improved the product.

Since I wasn't comfortable with the system's security, I initially kept the repository quiet and undisclosed. Afterward, however, I realized this was a contradiction, as I knew that security without transparency is not the best practice.

Also, we were not free from human errors. For example, RFID values were long strings of digits, and there were a few mistakes that someone would input in the charge amount, making the charge amount something like Integer.MAX_VALUE. We could've added a simple confirmation prompt, but we didn't know the mistakes would happen at that time.

In hindsight, it was such a great experience for me, who had never done large-scale real-life projects. I found myself compromising even after acknowledging the anti-patterns. I also understood that knowing and doing are two completely different things since knowing has no barriers, but doing accompanies extreme stress both in time and environment.

Still, it was such an exciting project.

Lastly, I want to thank everyone who made MinsaPay possible.

  • Jueon An, a talented developer who created MinsaPay with me
  • The KMLA student council and Department of Finances and Information, who oversaw the entire MinsaPay Initiatives
  • The open-source developers who reported the security flaws
  • Users who experienced server failures during the festival day
  • And the 400 users of MinsaPay

Thank you!

👋

👋
📜Heads up!
  • I wrote this post more than 3 years ago.
  • That's enough time for things to change.
  • Possibly, I may not endorse the content anymore.
Google Latest Articles Instead

counting...
danger

This post was written when I had little experience with Node.js. This is not an advisable way. This post simply serves as a departure post for my journey.

I have used AWS Elastic Beanstalk for a while and figured Heroku has several advantages over AWS. So I have migrated my AWS EB app called KMLA Forms to Heroku. For your information, KMLA Forms is a web app that simplifies writing necessary official documents in my school, KMLA.

Few advantages I found:

  1. Money. AWS costs money after its free tier limit. Since some of the students in my school used my web app, I have got some traffic, and AWS started to ask me about ~$10/month. As far as I know, there is no free tier traffic limit on Heroku.
  2. Native HTTPS support. Heroku natively supports HTTPS since every dyno app can use Heroku's domain. AWS EB, on the other hand, does not provide this. You need to configure your web domain and HTTPS Certificate for each web domain. Not valid for casual developers.

I had to make only minimal changes to app.js and package.json.

AWS Version

// ...

http.createServer(app).listen(8081, '0.0.0.0')

console.log('Server up and running at http://0.0.0.0:8081')

Heroku Version

// ...

const port = process.env.PORT || 8000

// ...

app.listen(port, () => {
console.log('App is running on port ' + port)
})

Also, I have added "start": "node app.js" in package.json. Codes are on GitHub, and the web is launched here.