當你啟動一個新的 Amazon Linux 2 AMI 服務器並嘗試使用以下命令安裝 PHP：
yum install php
成功安裝後，如果你使用 php -v檢查版本，你會看到：
PHP 5.4.16 (cli) (建立日期: 2019年10月31號 18:34:05 )
不過，最新的PHP版本是7.2，你可能希望使用這個新版本。
你可以透過 Amazon Linux Extras 啟動 PHP 7.2，使用以下命令：
sudo amazon-linux-extras enable php7.2
一旦已經啟動，按照接下來的指示完成安裝：
yum clean metadata
yum install php-cli php-pdo php-fpm php-json php-mysqlnd
就這樣。再次使用 php -v檢查 PHP 版本，現在應該會顯示：
PHP 7.2.28 (cli) (建立日期: 2020年3月2日 19:38:11 ) ( NTS )
I recently faced the task of analyzing a massive dataset consisting of log files. When I attempted to open the file in Excel, my laptop simply froze. Given the limitations of the tools available, I decided to parse the file using a Node.js script.
To read a small file, you might use the following script:
var fs = require("fs")
fs.readFile("path/mySmallFile.txt", "utf-8", (err, data) => {
if (err) {
throw err
}
console.log(data)
})
Using this script, you should be able to read the content of a small file. However, for large files, you might encounter a buffer error like RangeError: Attempt to allocate Buffer larger than maximum size. The script would terminate, producing an error similar to the following:
Error: "toString" failed
at stringSlice (buffer.js)
at Buffer.toString (buffer.js)
at FSReqWrap.readFileAfterClose [as oncomplete]
To read a large file, you can use Node.js's native readline library like so:
var fs = require("fs")
var readline = require("readline")
const rl = readline.createInterface({
input: fs.createReadStream("path/largeFile.csv"),
output: process.stdout,
terminal: false,
})
rl.on("line", line => {
console.log(line)
})
rl.on("pause", () => {
console.log("Done!")
})
Replace the file path with the path to your large file. Inside the on('line') function, you can process the file line by line—such as parsing it into JSON and incrementing a counter. The final sum can be displayed using the on('pause') function after the file has been completely read.
With this approach, you should now be able to process massive datasets using Node.js. For more information, please refer to the official documentation: Node.js Readline API.
Hello everyone and welcome back to another episode of Continuous Improvement. I'm your host, Victor, and today we're going to tackle a common problem that many of us face when dealing with large datasets: reading massive log files.
Recently, I had to analyze a massive dataset consisting of log files and when I tried opening it in Excel, my trusty laptop simply froze. Frustrating, right? Luckily, I found a solution using Node.js that I want to share with you today.
So, let's dive into the problem. Imagine you have a small file and you want to read its content using a script. You might use something like this:
[Script excerpt: fs.readFile]
This script works perfectly fine for small files. However, when it comes to large files, you might encounter an error like the following:
[Script error excerpt]
Ouch, that's definitely not what we want. But fear not, there's a solution! Instead of using fs.readFile, we can leverage Node.js's native readline library to tackle larger files.
Here's how it works:
[Script excerpt: readline.createInterface]
With this approach, we create a readline interface for our large file, setting the input as the file stream and the output as the standard output. Then, we can use the line event to process each line of the file, and the pause event to indicate when we're done reading the file.
By processing the file line by line, you can perform various operations like parsing the lines into JSON or incrementing a counter. And once the file has been completely read, you can display the final results.
And there you have it! Using this Node.js readline approach, you can now process massive datasets without running into buffer errors. If you want to dive deeper, I highly recommend checking out the official documentation for the Node.js Readline API.
I hope you found this solution helpful. Remember, continuous improvement is all about finding better ways to solve problems and streamline our processes.
Thank you for tuning in to Continuous Improvement. I'm Victor, your host, and I'll see you in the next episode. Keep improving!
我最近面臨了分析由日誌文件組成的大數據集的任務。當我試圖在Excel中打開這個文件時，我的筆記本電腦簡直凍結了。鑑於可用工具的限制，我決定使用Node.js腳本解析該文件。
要讀取一個小文件，你可能會使用以下腳本：
var fs = require("fs")
fs.readFile("path/mySmallFile.txt", "utf-8", (err, data) => {
if (err) {
throw err
}
console.log(data)
})
使用此腳本，你應該能夠讀取小文件的內容。然而，對於大文件，你可能會遇到緩存錯誤，例如 RangeError: 嘗試分配的緩衝區大於最大大小。該腳本將終止，產生類似於以下的錯誤：
Error: "toString" failed
at stringSlice (buffer.js)
at Buffer.toString (buffer.js)
at FSReqWrap.readFileAfterClose [as oncomplete]
要讀取一個大文件，你可以像這樣使用Node.js的本地 readline庫：
var fs = require("fs")
var readline = require("readline")
const rl = readline.createInterface({
input: fs.createReadStream("path/largeFile.csv"),
output: process.stdout,
terminal: false,
})
rl.on("line", line => {
console.log(line)
})
rl.on("pause", () => {
console.log("Done!")
})
將文件路徑替換為你的大文件的路徑。在 on('line')函數內部，你可以逐行處理文件，例如將其解析為JSON並增加計數器。完成閱讀文件後，可以使用 on('pause')函數顯示最終總和。
使用這種方法，你現在應該能夠使用Node.js處理大量數據集。有關更多信息，請參閱官方文檔：Node.js 讀取API。
In this article, I'm going to explain how to migrate your local WordPress MySQL database to Amazon Web Services (AWS) Relational Database Service (RDS). You might want to do this for the following benefits:
Convinced? Here are the steps to accomplish this migration:
First, navigate to the AWS console and choose RDS. Create a MySQL database, filling in the form as shown below:
DB Instance Identifier: wordpress Master Username: admin Master Password: [YourChoice]
You can leave most settings at their default values, including the default VPC.
Second, edit the security group of this newly created database. Select the database, navigate to the Connectivity and Security tab, and choose the security group. In the inbound rule tab, edit the inbound rule to remove the default settings and choose the type: MySQL, Protocol: TCP, and Port range: 3306.
In the source section, you may either choose the security group associated with your WordPress EC2 instance or enter your own IP address. If you haven't created your WordPress EC2 instance yet, you can do it now, or simply use Bitnami WordPress from the marketplace.
Third, SSH into your WordPress instance and back up your existing WordPress database with this command:
mysqldump -u root -p [YourDatabaseName] > backup.sql
Replace [YourDatabaseName] with the name of your database, such as bitnami_wordpress. The backup.sql file should be created in your current directory. Import this file to your newly created AWS RDS instance by running the command:
mysql -u admin -p -h [RDS_ENDPOINT] -D wordpress < backup.sql
Replace admin and [RDS_ENDPOINT] with your own values. If you encounter an error like:
ERROR 1049 (42000): Unknown database 'wordpress'
This means that your wordpress database has not been created yet. First, connect to the database with the command:
mysql -h [RDS_ENDPOINT] --user=admin --password=[YourPassword]
Once connected to MySQL, create a new database with the command:
mysql> CREATE DATABASE wordpress;
Query OK, 1 row affected (0.00 sec)
mysql> exit;
Bye
Finally, edit the wp-config.php file in your WordPress EC2 instance. This file is usually located in your WordPress directory, such as /home/bitnami/apps/wordpress/htdocs if you're using Bitnami. Update the following values:
/** The name of the database for WordPress */
define( 'DB_NAME', 'wordpress' );
/** MySQL database username */
define( 'DB_USER', 'admin' );
/** MySQL database password */
define( 'DB_PASSWORD', '[YourPassword]' );
/** MySQL hostname */
define( 'DB_HOST', '[RDS_ENDPOINT]' );
Replace the placeholders with your own values and save the file. The changes should take effect immediately.
Done. Feel free to reach out if you have any questions.
Hello everyone, and welcome to another episode of Continuous Improvement. I'm your host, Victor, and today we have an exciting topic to discuss - migrating your local WordPress MySQL database to Amazon Web Services Relational Database Service, also known as RDS. If you've been considering this migration for improved performance, database scalability, and easier maintenance, then you've come to the right place. So let's dive right into it.
The first step is to navigate to the AWS console and choose RDS. From there, you'll need to create a MySQL database. Simply fill in the form as shown, including the DB Instance Identifier, Master Username, and Master Password. Most of the settings can be left at their default values, including the default VPC. If you're unsure, don't worry, we'll guide you through the process.
Next, it's time to back up your existing WordPress database. SSH into your WordPress instance and use the command mysqldump -u root -p [YourDatabaseName] > backup.sql to create a backup of your database. Remember to replace [YourDatabaseName] with the actual name of your database, such as bitnami_wordpress. This backup file will be crucial in the migration process.
Now that you've backed up your database, it's time to import it into your newly created AWS RDS instance. Use the command mysql -u admin -p -h [RDS_ENDPOINT] -D wordpress < backup.sql to import the backup. Just remember to replace admin and [RDS_ENDPOINT] with your own values. If you encounter any issues during this step, we've got your back.
In case you come across an error stating "ERROR 1049 (42000): Unknown database 'wordpress'," it means your wordpress database hasn't been created yet. Don't worry, it's an easy fix. Start by connecting to the database using mysql -h [RDS_ENDPOINT] --user=admin --password=[YourPassword]. Once connected, create a new database with the command mysql> CREATE DATABASE wordpress;. Make sure you exit MySQL after creating the database.
Lastly, you'll need to edit the wp-config.php file in your WordPress EC2 instance. This file is typically located in your WordPress directory, such as /home/bitnami/apps/wordpress/htdocs if you're using Bitnami. Update the values for DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST to match your newly created RDS instance. Once you've made the changes, save the file, and you're all set!
And that's it! You've successfully migrated your local WordPress MySQL database to AWS RDS. Now you can enjoy improved performance, scalability, and easier maintenance of your website. If you have any questions or need further assistance, feel free to reach out. We're here to help you every step of the way.
Thank you all for tuning in to this episode of Continuous Improvement. I hope you found this guide helpful and that it inspires you to take advantage of the benefits AWS RDS can offer for your WordPress database. Stay tuned for more episodes focused on helping you improve your workflows, technology, and more. I'm Victor, your host, signing off. Until next time!
在這篇文章中，我將說明如何將您本地的WordPress MySQL資料庫遷移到Amazon Web Services（AWS）關聯性資料庫服務（RDS）。你可能會想要這樣做以獲取以下好處：
信服了嗎？下面是達成此次遷移的步驟：
首先，導航到AWS控制台並選擇RDS。建立一個MySQL資料庫，如下圖所示填寫表單：
DB實例識別碼： wordpress 主用戶名： admin 主密碼： [YourChoice]
您可以將大多數設置保留為其預設值，包括預設的VPC。
其次，編輯這個新建的資料庫的安全組。選擇資料庫，導航至連接和安全標籤，並選擇安全組。在入站規則標籤中，編輯入站規則以移除預設設定並選擇類型：MySQL，協議：TCP，以及端口範圍：3306。
在來源部分，您可以選擇與您的WordPress EC2實例相關聯的安全組，或者輸入您自己的IP地址。如果您還未創建您的WordPress EC2實例，現在你可以做，或者只需從市場使用Bitnami WordPress。
第三，SSH進入您的WordPress實例，並用此命令備份您現有的WordPress資料庫：
mysqldump -u root -p [YourDatabaseName] > backup.sql
將[YourDatabaseName]替換為您的資料庫名稱，例如bitnami_wordpress。應在您的現有目錄中創建backup.sql文件。通過運行命令將此文件導入到您新建的AWS RDS實例：
mysql -u admin -p -h [RDS_ENDPOINT] -D wordpress < backup.sql
將admin和 [RDS_ENDPOINT]替換為您自己的值。如果您遇到如下的錯誤：
ERROR 1049 (42000): Unknown database 'wordpress'
這表示您的wordpress資料庫尚未被創建。首先，用以下命令連接到資料庫：
mysql -h [RDS_ENDPOINT] --user=admin --password=[YourPassword]
一旦連接到MySQL，就用以下命令創建一個新的資料庫：
mysql> CREATE DATABASE wordpress;
Query OK, 1 row affected (0.00 sec)
mysql> exit;
Bye
最後，編輯您的WordPress EC2實例中的wp-config.php文件。該文件通常位於您的WordPress目錄中，例如倘若您使用的是Bitnami，那麼它位於/home/bitnami/apps/wordpress/htdocs。更新下列值：
/** The name of the database for WordPress */
define( 'DB_NAME', 'wordpress' );
/** MySQL database username */
define( 'DB_USER', 'admin' );
/** MySQL database password */
define( 'DB_PASSWORD', '[YourPassword]' );
/** MySQL hostname */
define( 'DB_HOST', '[RDS_ENDPOINT]' );
使用您自己的值替換占位符並保存文件。更改應立即生效。
完成。如果您有任何問題，請隨時聯繫我。
If you are a Mac user who also uses Git, you might accidentally commit a .DS_Store file. This could confuse your Windows colleagues, who may wonder what these files do and why you've committed them.
First, what is a .DS_Store file? DS stands for Desktop Services, and these files are used by Macs to determine how to display folders when you open them. For example, they store custom attributes like the positions of icons. These files are created and maintained by the Finder application on a Mac, and are normally hidden.
These .DS_Store files are not useful to Windows users and do not need to be committed to your GitHub repository. To remove existing .DS_Store files from your repository, run the following command:
find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch
Afterwards, commit the changes to remove those files and push to the remote repository. To prevent these files from being added again, edit your .gitignore file and add the following line:
.DS_Store
Doing so will address any concerns your colleagues may have.
Welcome back to another episode of Continuous Improvement, the podcast where we discuss tips and tricks for enhancing your productivity and problem-solving abilities. I'm your host, Victor, and in today's episode, we'll be addressing a common issue faced by Mac users who also use Git.
If you're a Mac user who has accidentally committed a .DS_Store file, you might be wondering why this is a problem and how it can confuse your Windows colleagues. Well, fear not, because today I'll be sharing some insights on what these files are and how you can avoid committing them.
So, what exactly is a .DS_Store file? The 'DS' in .DS_Store stands for Desktop Services, and these files are used by Macs to determine how to display folders when you open them. They store custom attributes such as the positions of icons and are created and maintained by the Finder application on a Mac. Normally, these files remain hidden from view.
However, for Windows users, these .DS_Store files aren't useful and can cause confusion when they find them in a Git repository. Fortunately, there's a straightforward solution to remove these files from your repository.
To remove existing .DS_Store files, you'll need to run a simple command in your terminal. Here's what you need to type:
find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch
This command will find all the .DS_Store files in your repository and remove them. Remember to commit the changes and push them to your remote repository to ensure these files are permanently removed.
But how do you prevent .DS_Store files from being added again in the future? It's simple! You just need to edit your .gitignore file and add the following line:
.DS_Store
By adding this line to your .gitignore file, you're telling Git to ignore any .DS_Store files that are present in your repository.
By following these steps, you'll address any concerns your Windows colleagues may have about these files and maintain a cleaner, more organized Git repository.
That concludes today's episode of Continuous Improvement. I hope you found this information valuable and will be able to implement these steps in your own Git workflow. Thank you for tuning in, and remember to keep striving for continuous improvement!
如果你是一個同時使用 Mac 和 Git 的用戶，你可能會無意間提交 .DS_Store 文件。這可能會讓你的 Windows 同事感到困惑，他們可能不清楚這些文件的用途，也不明白你為何要提交它們。
首先，什麼是 .DS_Store 文件？ DS 代表桌面服務（Desktop Services），這些文件被 Mac 用來確定當你打開它們時如何顯示文件夾。例如，它們存儲自定義屬性，如圖標的位置。這些文件由 Mac 的 Finder 應用程序創建並維護，並且通常是隱藏的。
這些 .DS_Store 文件對 Windows 用戶無益，也不需要提交到你的 GitHub 倉庫。要從你的倉庫中移除現有的 .DS_Store 文件，執行以下命令：
find . -name .DS_Store -print0 | xargs -0 git rm -f --ignore-unmatch
然後，提交更改以移除這些文件，並推送到遠程倉庫。為了防止這些文件再次被添加，編輯你的 .gitignore 文件，並添加以下行：
.DS_Store
這樣做將避免你的同事產生任何疑慮。