My book is labeled as a bestseller at Naver

"Electric Car - Common Sense Dictionary (์ „๊ธฐ์ฐจ ์ƒ์‹์‚ฌ์ „)" has a red "bestseller" tag on it in Naver search results

Kyobo's weekly bestsellers
It's been about two weeks since my new book officially went on sale at various online and offline bookstores around Korea. The book saw its interest surging the subsequent Monday (August 30, 2021), and so it peaked at 32nd position of the tech / engineering online weekly bestsellers at Kyobo Book Centre the next day.

The wave has somewhat calmed down at the moment, but for some reason Naver has now decided to label it as a bestseller. I first spotted the red tag on September 4, before disappearing just a day after. It then returned today (September 7). I'm not sure what this classification is based on, but I guess the book is doing well.
Defined tags for this entry: , , , ,

My new book is available on pre-order

"Electric Car - Common Sense Dictionary (์ „๊ธฐ์ฐจ ์ƒ์‹์‚ฌ์ „)" book listed on Yes24

A few months ago, I had the idea to gather all sorts of replies and posts I made in the electric vehicle-oriented communities on the Internet and organize them into a single book called "Electric Car - Common Sense Dictionary". Luckily, one of the major publishers I sent the first draft to thought it would sell and decided to publish it. So after beefing up the content and updating the data up to the last minute, the final manuscript was sent off to the press yesterday. And as of today all the major bookstores in the country have listed it for pre-order. Official release is slated for August 25, 2021. Here are where you can find it (all in Korean).

Official page at the publisher (Nexus)

- Kyobo Book Centre
- Youngpoong Bookstore
- Interpark
- Aladin
- Yes24
Defined tags for this entry: , , ,

I've seen more than a thousand EVs in Naju

Kona, Ioniq, Bolt EV, Niro, and SM3 ZE make up 80% of total EVs I saw in Naju

Since buying my own EV back in June 2018, I started to notice other electric vehicles in the city. So the "EV spotting" became a hobby of mine ever since. Including seven that I found in the photos I took between July 2017 and May 2018, I saw a total of 1,030 different EVs up to April 20, 2021. Here are some of the statistics from the data.

As with the internal combustion engine cars, Hyundai is the dominant player. Its two best-selling models, Kona Electric (36.0%, 370 units) and Ioniq Electric (15.0%, 154 units), take up over half of all the cars I came across. In fact, Kona was seen more often than the major models from other big players - Niro EV (11.3%, 116 units), Bolt EV (10.2%, 105 units), SM3 ZE (7.6%, 78 units), and Soul EV (4.8%, 49 units) - which account for only 33.8% (348 units) together. I should note that Ioniq, Bolt EV, and SM3 ZE were dominant early on because they started selling earlier than other models. But Kona (and to a lesser extent, Niro) eventually rose to the top.

Meanwhile, Tesla Model 3 (3.5%, 36 units) and the hydrogen fuel cell powered Nexo (4.5%, 46 units) have been rising in popularity quite recently and are starting to take bigger slices of the pie. EV versions of the signature 1-ton trucks Porter (1.7%, 18 units) and Bongo (1.2%, 12 units) have also started to make a dent. But other than the ones I mentioned so far, I was not able to find other cars in double digits, and that includes the BMW i3 (0.6%, 6 units) in the chart. These "others" make up 4.5% (46 units), which includes rarities like Hyundai BlueOn (first mass-produced battery EV) and Tucsan (first mass-produced hydrogen FCEV).
71% of all the EVs I saw were local, either from Naju or Gwangju

By looking at the pattern of the license plate numbers with other visible cues, it's possible to infer where the car was registered at without searching the official records. As it was expected, the much of the cars are local, with 41.7% (430 units) apparently from within the city. Cars from the much more populous neighbouring city of Gwangju (1.471 million, as opposed to 116 thousand in Naju) also take out a big chunk, with 29.4% (303 units) of total. Vehicles with rental license plates make up another 8.3% (85 units). The rest are suspected to be from other regions, although some may be local but not yet positively determined.

One thousand is a big number, but the EV market is just starting to bloom. I'll be interesting to see how different the chart will look with another thousand cars added in.
Defined tags for this entry: , ,

Server upgraded to macOS Big Sur

iMac stuck on Setting Up Account step of the macOS Big Sur upgrade

I skipped upgrading the iMac serverโ€™s OS to macOS 10.15 Catalina last year mainly due to the removal of 32-bit application support. After a year, the clean-up of obsolete apps was complete, paving the way for the upgrade.

During the preparation, there was a bit of a hiccup with the MySQL database, But putting the data to a new one largely solved the issue and the website ended up loading much quicker. Two minor errors occurred after moving to the new database, which were quickly resolved by editing the configuration file:

1. "Query failed: Out of sort memory, consider increasing server sort buffer size"

Solution: increase sort_buffer_size from the default of 262144
sort_buffer_size=2097152

2. "Query failed: Expression #1 of SELECT list is not in GROUP BY clause and contains nonaggregated column 'blog.multilingual_body.value' which is not functionally dependent on columns in GROUP BY clause; this is incompatible with sql_mode=only_full_group_by"

Solution: remove only_full_group_by in sql_mode
sql_mode=STRICT_TRANS_TABLES, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_ENGINE_SUBSTITUTION

With all the pieces ready I went with the installation of macOS 11.0 Big Sur. It took about an hour and except for a prolonged setup time of the iCloud, things went smoothly.

Defined tags for this entry: , , , ,

Adventures in fixing broken Korean text in MySQL DB

The Tool-Box.info website has been running on the Apache - PHP - MySQL (APM) solution for the past 13 years. Each component has been constantly upgraded over the years, and recently I decided to update MySQL from 5.7 to 8.0. Once I managed to migrate the database to the new version, I discovered that all the Korean texts on the website came out broken. This was a sign of mismatched character set, so I looked for the exact cause.

First, I rolled back to 5.7 and checked what character sets were being used, using the following SQL query:
show variables like 'char%';

Sure enough, "character_set_database" and "character_set_server" were set to "latin1". Upon checking the database and the tables that contain the website data, their character sets were all set to "latin1_swedish_ci", the default choice. All the Korean texts were being saved to the database in Latin1 format from the very beginning. It got converted into UTF-8 as it was passed to the output, so it looked normal when viewed through a web page. But if you looked directly into the database, it came out broken. MySQL 8.0 apparently decided to output the text in its saved form, unlike 5.7, hence the problem.

The solution proposed by many of the Korean blogs that had a similar problem was to alter the character set of the affected databases and tables in the following manner:
ALTER DATABASE data_database CHARACTER SET = utf8mb4 COLLATE = utf8mb4_unicode_ci;

ALTER TABLE data_table DEFAULT CHARSET=utf8mb4;

ALTER TABLE data_table MODIFY COLUMN title VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_general_ci;

And also, add the following lines under [mysqld] in the MySQL configuration file (my.cnf):
collation-server = utf8_unicode_ci
character-set-server = utf8

Sadly, all this did not help one bit. Upon further analysis, I arrived at the conclusion that the underlying data was still in "broken" form even if the settings had the character set changed. The data itself has to be rewritten in UTF-8, so I needed to dump the database and reload it in the correct character set. First, the dump:
mysqldump -u root -p --default-character-set=latin1 data_database > dump.sql

The "default-character-set" flag was set to "latin1" to ensure that the data is dumped in its originally saved character set. In the dumped file, I changed all the "latin1" strings into "utf8mb4".

Now I simply had to restore it back, but the "Specified key was too long; max key length is 1000 bytes" error prevented me from restoring some of the tables. I tracked the problem down to the limitation of the MyISAM database type. Because the "VARCHAR" data type for a column needs 3 times more space for UTF-8 than Latin1, the character set change caused the key length to exceed the 1000-byte limit. With InnoDB database type, it was 3072 bytes by default since MySQL 5.7.7.

Because of this, I changed the database type mentioned in the file from MyISAM to InnoDB. So why was it set to MyISAM in the first place? It was because Full-text index was not available for InnoDB at the time of the database creation. It was enabled in 2011 with MySQL 5.6.

With both the database type and character set changed in the dump file, I restored the database like this:
mysql -u root -p --default-character-set=utf8mb4 data_database < dump.sql

I could now see that all the Korean text appeared correctly in the database. It would also look right on the website if I kept the changes to the my.cnf file mentioned earlier. Finally, I migrated the database to MySQL 8.0 again, and ran the "mysql_upgrade" command. Everything was working as intended, and I no longer needed the changes to the my.cnf, so those were removed.

Long story short, initial database settings from 13 years ago almost held me back from upgrading to the newest MySQL version, but all of them are now fixed.
Defined tags for this entry: , ,

Copyright (C) 1996-2021 Wesley Woo-Duk Hwang-Chung. All rights reserved.