Building a Flickr-to-WordPress Importer with Claude Code

Back in 2018, Flickr decided to limit free accounts to 1000 photos, and like many non-professional photographers, I needed a way out. I started using a WordPress site as my replacement for Flickr to save new photos I wanted to share, calling it “A new replacement for Flickr.” Then I thought of building a small project to import my existing Flickr photos to WordPress.

Fast forward 7 years, and I finally picked up this project again – but this time with Claude Code as my coding partner. What started as a personal need became a fascinating experiment in mastering AI-assisted development.

You can check out the complete project on GitHub and see the imported photos in action on my photoblog. It’s pretty satisfying to see all those Flickr memories living in their new WordPress home.

Continue reading →

TIL: Associative Table and Many-to-Many Relationship

There are many terms calling this as discussed in this stackoverflow, and even in this Wikipedia page:

Associative tables are colloquially known under many names, including association table, bridge table, cross-reference table, crosswalk, intermediary table, intersection table, join table, junction table, link table, linking table, many-to-many resolver, map table, mapping table, pairing table, pivot table (as used incorrectly in Laravel—not to be confused with the correct use of pivot table in spreadsheets), or transition table.
https://en.wikipedia.org/wiki/Associative_entity

It’s even more interesting that http://en.wikipedia.org/wiki/Junction_table is being redirected to https://en.wikipedia.org/wiki/Associative_entity.

About what it is:

In database design, associative tables are utilized to manage many-to-many relationships between entities. When two entities have a relationship where one instance of the first entity can be associated with multiple instances of the second entity, and vice versa, an associative table is necessary to manage this relationship.

For example, in a library database, a book can be written by multiple authors, and an author can write multiple books. To represent this many-to-many relationship, an associative table, often called a junction table, is used. This table typically contains the primary keys of the two entities it is connecting (in this case, books and authors).

The associative table helps in avoiding data redundancy and ensures efficient management of the many-to-many relationship without the need for complex hierarchical structures or duplicating data. It forms a crucial element in relational database design, enabling the establishment and maintenance of robust associations between entities.
Explained by AI.

TIL – More about Kafka, Two Generals’ Problem and Duplicate Payments

The concepts of an event-driven system, the Two Generals’ Problem, and duplicate payments are interconnected through the themes of communication, coordination, and consistency in distributed systems.

Event-Driven Systems

An event-driven system, such as Apache Kafka, is designed to handle the production and consumption of events asynchronously. In such a system, events represent changes in state or occurrences that are processed by different components. This approach allows for high scalability and flexibility as components can operate independently and react to events as they occur.

Two Generals’ Problem

The Two Generals’ Problem illustrates the challenges of achieving reliable communication between distributed parties. It describes a scenario where two armies (generals) want to coordinate an attack on a fortress. They can only communicate via messengers, but the messengers may be intercepted. This problem highlights that without a guaranteed acknowledgment of receipt, it is impossible for either general to be sure that the other has received the plan, leading to potential failure in coordination.

Duplicate Payments

Duplicate payments in an event-driven system can occur when an event (e.g., a payment transaction) is processed multiple times due to a lack of reliable acknowledgment or due to retries caused by failures in communication. If a system cannot confirm that a payment has been securely processed, it may send the same event again, leading to duplicate transactions.

Relationship

Communication and Acknowledgment: Both the Two Generals’ Problem and duplicate payments emphasize the necessity of proper acknowledgment mechanisms in event-driven systems. In Kafka, for example, the producer can receive acknowledgments to ensure that messages are delivered and stored correctly.
Coordination: Like the generals who must coordinate their attack, systems using Kafka must handle events in a way that multiple components can work together without conflicts. This coordination is critical to prevent inconsistencies such as duplicate payments.
Consistency: Event-driven architectures must implement strategies to maintain consistency across distributed systems. Addressing the Two Generals’ Problem requires building systems that reliably acknowledge the processing of events to avoid issues like duplicate payments.

In conclusion, event-driven systems like Kafka must navigate the challenges highlighted by the Two Generals’ Problem to ensure reliable communication, which is essential to preventing duplicate payments and maintaining overall system integrity.

TIL – MySQL Data Type DECIMAL

This data type comes up when we design a column to store money amount. We’d like to have accuracy and avoid the funny famous issue in programming 0.1 + 0.2 !== 0.3.

The MySQL data type DECIMAL (with NUMERIC as its alias) is used for storing decimal numbers with fixed precision and scale. It is suitable for dealing with precise numeric values where accuracy is crucial, such as monetary amounts.

Continue reading →

TIL – MySQL ON DUPLICATE KEY UPDATE

// Start written by AI ChatGPT

The ON DUPLICATE KEY UPDATE statement in MySQL is used when you want to either insert a new row into a table or update the existing row if a duplicate key constraint is violated. In other words, it allows you to handle duplicates gracefully.

Continue reading →

TIL – Message Queue

Key points:

A message queue is a form of asynchronous service-to-service communication used in serverless and microservices architectures.
Calling it “queue” because of that messages are pulled in the mechanism of FIFO (First in First Out).
Different styles of message queuing: point-to-point (one message is received by one consumer), and Publish/Subscribe (one message is received by multiple consumers).

Continue reading →

TIL – It’s more clear Data Mapper – Active Record, ORM?

Active Record is a design pattern where the model is responsible for both the data and the behavior related to that data, allowing direct interaction with the database through the model itself. In contrast, the Data Mapper pattern separates the in-memory objects from the database, using a repository to manage data access, which is more suitable for larger applications. There is a pretty good explanation here https://typeorm.io/active-record-data-mapper/

Some examples regarding these patterns:

For WooPayments server, we use Data Mapper: Repository (all database actions are here) <> Model (Entity). It’s actually good for the large applications like it.
Laravel, by default, uses the Active Record pattern as its models interact directly with database. But it’s also possible to use Data Mapper pattern in Laravel.

ORM (Object-Relational Mapping) is a programming technique that enables developers to interact with relational databases using high-level object-oriented programming languages, abstracting the complexities of SQL. By mapping database tables to programming objects, ORM allows for seamless data manipulation through objects rather than cumbersome queries. This approach enhances productivity, increases code readability, and helps prevent security issues like SQL injection. The “Patterns of Enterprise Application Architecture” book by Martin Folwer is a good source for this.

TIL – Term “God/Godlike Object”

Today, I encountered the “godlike object” term, and here is what it is:

In object-oriented programming, a god object (sometimes also called an omniscient or all-knowing object) is an object that references a large number of distinct types, has too many unrelated or uncategorized methods, or some combination of both. The god object is an example of an anti-pattern and a code smell.
https://en.wikipedia.org/wiki/God_object

This is somewhat every developer would avoid, especially when working on a large codebase. Remember two relevant terms: “divide and conquer strategy” in algorithm and “single-responsibility principle” in OOP.

TIL – WebAuthn

WebAuthn is considered more secure than traditional two-factor authentication (2FA) methods like Google Authenticator or Duo because it is linked directly to a specific device, offering a stronger guarantee against phishing attacks. However, this device dependency also makes it less portable, as users may find it challenging to authenticate from different devices or in scenarios where their primary device is unavailable.

Some good reference:

TIL – Timing Attack

Question: Why should we use hash_equals in PHP rather than just the simple string comparison?

Answer: Actually, it’s not something PHP specific. Instead, it’s universal among all programming languages. But why? With the typical string comparison, the false result will be emitted as soon as a non-matched character is found. By trying to compare the response time in a fast network (such as local LAN) from different string lengths and content, attackers can slowly verify the correct secret string. hash_equals ensures that there is no difference in terms of response time.

References: