Skip to content

Home

將WordPress MySQL資料庫遷移到AWS RDS

在這篇文章中,我將說明如何將您本地的WordPress MySQL資料庫遷移到Amazon Web Services(AWS)關聯性資料庫服務(RDS)。你可能會想要這樣做以獲取以下好處:

  1. 改善性能,因為您的資料庫將與在EC2實例上運行的資源分開。
  2. 能夠橫向伸縮您的網站,允許多個EC2實例連接到同一個資料庫。
  3. 更容易進行資料庫維護和升級任務。

信服了嗎?下面是達成此次遷移的步驟:

首先,導航到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]' );

使用您自己的值替換占位符並保存文件。更改應立即生效。

完成。如果您有任何問題,請隨時聯繫我。

Removing .DS_Store Files from Git Repositories

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.

從 Git 倉庫中移除 .DS_Store 文件

如果你是一個同時使用 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

這樣做將避免你的同事產生任何疑慮。

Ignoring Already Modified Files in Git

I've encountered a rare scenario where a file has been modified, but I don't want to commit this change to Git. There are various methods to achieve this, such as using a .gitignore file. However, this approach doesn't work if the file is already being tracked.

The solution is to manually ignore the file by executing the following command:

    git update-index --assume-unchanged <file path>

To start tracking the file again, you can revert this action by using the following command:

    git update-index --no-assume-unchanged <file path>

Feel free to reach out if you have any questions.

在Git中忽略已修改的文件

我遇到了一種罕見的情況,一個文件已經被修改,但是我不想將這個變更提交給Git。有各種方法可以實現這一點,比如使用.gitignore文件。然而,如果文件已經被追蹤,這種方法就不起作用。

解決方案是通過執行以下命令來手動忽略文件:

    git update-index --assume-unchanged <文件路徑>

要再次追蹤文件,您可以通過使用以下命令來撤消此操作:

    git update-index --no-assume-unchanged <文件路徑>

如果您有任何問題,請隨時聯繫我。

Find and Kill Processes Locking Specific Ports on a Mac

Problem: Sometimes, when you start a local Node.js server, it may continue running in the background. If you try to start the server again, you may encounter an error indicating that the port (e.g., 8080) is already in use and locked:

    throw er; // Unhandled 'error' event
    Error: listen EADDRINUSE 127.0.0.1:8080

Solution: You can use the lsof command to identify the process locking the port:

    lsof -n -i4TCP:8080

Alternatively, you can replace 8080 with the specific port number you want to investigate. This will display a list of processes currently using that port. Identify the process you wish to terminate (for example, node running with PID 6709) and execute the following command to kill it:

    kill -9 <PID>

Finally, restart your server. It should run normally once the port has been freed.

在 Mac 上尋找並終止鎖定特定端口的進程

問題:有時候,當您啟動一個本地 Node.js 服務器時,它可能會繼續在後台運行。如果您嘗試再次啟動服務器,您可能會遇到一個錯誤,指出端口(例如,8080)已經在使用中並被鎖定:

    throw er; // Unhandled 'error' event
    Error: listen EADDRINUSE 127.0.0.1:8080

解決方案:您可以使用 lsof 命令來識別鎖定端口的進程:

    lsof -n -i4TCP:8080

或者,您可以將 8080 替換為您想要調查的特定端口號。這將顯示當前使用該端口的進程列表。識別您希望終止的進程(例如,正在運行的 node 與 PID 6709)並執行以下命令來將其殺死:

    kill -9 <PID>

最後,重新啟動您的服務器。一旦端口被釋放,它應該可以正常運行。

How to Work with a Product Manager as a Software Engineer

As a software engineer, I know how it feels to work with product managers. With years of experience, I've encountered fantastic Product Managers (PMs) as well as some less-than-ideal ones. Every day, I collaborate with PMs, and I understand the challenges that can arise, particularly when the relationship is strained. In this blog post, I'll offer advice on how to work effectively with a PM as a software engineer.

Two primary difficulties can arise when working with PMs. The first issue is that a PM without an engineering background may not understand the technical complexities you're dealing with, leading to a lack of mutual respect. Secondly, if a PM started their career as an engineer, it can be frustrating to hear them talk as if they fully understand technical subjects like blockchains, big data, or artificial intelligence when they actually don't.

To bridge these gaps, soft skills and communication abilities are essential.

Common Pitfall 1: Technological Ignorance

The worst thing to hear from a PM is something like, "It's just a simple button. Are you sure you can't finish it in five minutes?" Such comments imply that the work is straightforward and that you are incompetent. But, creating even a simple button is not trivial. For example, Google's homepage search button is not just a "simple button." Various states like hover, click, double-click, and other factors like text localization, accessibility, and multiple screen widths must be considered.

Common Mistake 2: Misunderstanding Roles and Responsibilities

PMs are responsible for the product, but they are not your bosses. This misunderstanding can be especially prevalent in hierarchical organizational structures or where an outsourced vendor manages in-house PMs. Practicing methodologies like Scrum can help set boundaries and manage expectations. Frequent changes in requirements can be detrimental to the project, leading to non-reusable code, bugs, and technical debt.

Common Error 3: Lack of Clear Objectives

It can be frustrating when a PM has no clear vision and hasn't defined specific requirements. Engineers thrive on tackling challenges and require clear goals. Poorly defined requirements lead to a product that's hard to measure in terms of impact and success.

Final Thoughts

To navigate these issues successfully, here are my three recommendations:

  1. Treat non-technical stakeholders with empathy and kindness, while educating them on the complexities of your work.
  2. Understand that the PM is not your boss; collaborate and be willing to share credit for successes.
  3. Stay informed about industry trends and be prepared to construct a persuasive argument when you think the requirements are flawed.

Remember, software development is a team sport. Like any team, success depends on effective communication, collaboration, and leadership to achieve a common goal.

作為一名軟件工程師如何與產品經理合作

作為一名軟件工程師,我知道與產品經理合作的感覺。借助多年的經驗,我遇到過優秀的產品經理(PM)以及一些不理想的PM。每天,我都會與PM進行合作,我了解到可能出現的挑戰,特別是當彼此的關係變得緊張時。在這篇博客文章中,我將提供一些作為一名軟件工程師如何有效與PM合作的建議。

與PM合作時可能出現兩個主要的困難。第一個問題是,沒有工程背景的PM可能無法理解你正在處理的技術復雜性,導致彼此之間缺乏尊重。第二,如果PM的職業生涯始於工程師,他們如果說出自己完全理解像區塊鏈、大數據或人工智能等技術主題,實際上卻不然,會讓人感到困擾。

要縮小這些隔閡,軟技能和溝通能力是必不可少的。

常見的陷阱1:對科技的無知

從PM那裡聽到最讓人惱火的一句話可能就是, "這只是一個簡單的按鈕。你確定你五分鐘內完成不了嗎?"之類的評論暗示著工作很簡單,並且你是無能的。但是,創建即使是一個簡單的按鈕也並非小事。例如,Google首頁的搜索按鈕不只是一個”簡單的按鈕”。必須要考慮各種狀況,如懸停、點擊、雙擊,以及像文本語言化,訪問性和多個屏幕寬度等其他因素。

常見的錯誤2:誤解角色和責任

PM負責產品,但他們不是你的老闆。在等級組織結構中或者是由外包廠商管理的內部PM中,這種誤解可能尤其普遍。採用像精益求精這樣的方法可以幫助設定邊界並管理期望。需求的頻繁變更可能對項目造成傷害,導致無法重用的代碼,錯誤和技術債務。

常見的錯誤3:沒有清晰的目標

在PM沒有明確的願景並沒有定義具體的需求時,可能會讓人感到沮喪。工程師擅長解決挑戰並需要清晰的目標。需求定義不明會導致產品難以衡量影響和成功。

最後的想法

為了成功地應對這些問題,這裡有我的三個建議:

  1. 以同理心和善意對待非技術的利益相關者,同時讓他們了解你工作的復雜性。
  2. 理解PM並不是你的老闆;願意與他們合作並願意分享成功的成果。
  3. 對行業趨勢保持了解,並準備好在你認為需求有誤時進行有說服力的論述。

請記住,軟件開發是一個團隊運動。像任何隊伍一樣,成功取決於有效的溝通,合作和領導以實現共同的目標。

Registering Sling Servlets in Adobe Experience Manager

In Adobe Experience Manager (AEM), a Sling servlet can be utilized to handle certain RESTful request-response AJAX calls. Written in the Java programming language, these servlets can be registered as OSGi (Open Services Gateway Initiative) services. There are two methods to register a servlet in AEM: 1) By Path, and 2) By resourceType. Details for both are explained below:

1. Register by Path

For instance, if you want to execute a form POST request to the path /bin/payment from the client-side to the Sling servlet class, you can use the annotation below:

@SlingServlet(
    metatype = true,
    methods = { "POST" },
    paths = "/bin/payment"
)
public class YourServlet extends SlingSafeMethodsServlet {

    @Override
    protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException {
        // Perform your tasks here
    }
}

When there's a POST request to http://localhost:4502/bin/payment, the servlet will be triggered, and the doPost method will be invoked.

Prerequisites include having a local AEM instance up and running on port 4502 and installing the bundle module via the Maven bundle plugin. You can verify the installation of the bundle by navigating to http://localhost:4502/system/console/bundles. If it's not installed, you can manually upload the JAR file.

If you encounter a "forbidden" error and cannot serve the request to /bin/payment, follow these steps:

  1. Go to http://localhost:4502/system/console/configMgr.
  2. Search for 'Apache Sling Referrer Filter'.
  3. Remove the POST method from the filter. This will allow you to trigger the POST method from any source.
  4. Locate Adobe Granite CSRF Filter.
  5. Remove POST from the filter methods.
  6. Save the changes and test the servlet again.

The servlet should now trigger as expected.

2. Register by resourceType

To avoid the issues mentioned above, a better approach is to register the servlet by resourceType. Refactor the servlet as follows:

@SlingServlet(
    metatype = true,
    methods = { "POST" },
    resourceTypes = "services/payment"
)
public class YourServlet extends SlingSafeMethodsServlet {

    @Override
    protected void doPost(SlingHttpServletRequest request, SlingHttpServletResponse response) throws ServletException {
        // Perform your tasks here
    }
}

Next, you'll need to create a page to trigger this resource:

  1. Go to CRXDE Lite at http://localhost:4502/crx/de/index.jsp.
  2. Inside the /content folder, create a page (e.g., http://localhost:4502/content/submitPage.html).
  3. In the resourceType properties, enter services/payment or whatever matches your servlet above.
  4. Save your changes and test the POST request to http://localhost:4502/content/submitPage.html. It should work as expected.

Extra Tips: You can also use the Apache Sling Resource Resolver to verify if the servlet has been registered successfully at http://localhost:4502/system/console/jcrresolver.

Feel free to leave any questions in the comments below.