I'm trying to create an agent—hopefully a step toward AGI—without fully knowing what I'm doing. Just curiosity, ambition, and a lot of guesswork. Along the way, I’ve picked up thoughts and lessons—about complex systems, fractality, and beauty. Some feel useful, others are still confusing, and most remain unfinished. This is a collection of those fragments—short notes and insights from someone still finding their way.

Motivation, Goals, and Learning

1. Dreams, goals, and purpose are a volatile stack of expectations.
2. A human’s learning hyperparameter is the fear-to-curiosity ratio.
3. To learn is to both remember and forget. Specification demands memory; generalization, letting go.
4. Long-term memory is a graph of events; short-term memory is a set of floating contexts.
5. We generalize through expectation; we differentiate through surprise.
6. We generalize by letting go of the contexts tied to an event; we differentiate by anchoring the current floating contexts to it.
7. Recollection is the delicate dance between similarity search of contexts and simulation of events.
8. Excitement is the caching of confident actions, motivated to flush them when expectations are reached.
9. Curing any obsession or addiction involves tolerating actions you're not confident with. Likewise, always taking confident actions makes you prone to addiction and obsession.

Creativity, decision-making, and problem solving

1. Creativity arises when a goal is clear, but the connection between state A and state B is yet to be made.
2. Creativity is navigating uncertainty.
3. Navigating uncertainty is a delicate dance between curiosity and fear.
4. Navigating uncertainty is a cycle of ranking options and making decisions until you get your expectations. Different creatures ranks and evaluate decisions differently.
5. Fearful creatures ranks options by data, and evaluates based on gut. Curious creatures ranks options by gut, and evaluates based on data.
6. Fearful creatures' pitfall is quitting when they have no data.
7. Curious creatures' pitfall is unbounded hallucination.
8. Guessing all possible paths requires significant operational resources, which is why we often do it concurrently in our minds—through brainstorming.
9. The key difference between humans and other beings may lie in our ability to guess more accurately.
10. Likewise, good faith AGI robots or quantum computer minds will probably find our guesswork as cute as we find a dog's attempts to guess. I wonder if my cat thinks the same of a cockroach’s guesswork.
11. Bad faith AGI or quantum minds may not find our guesswork cute—they may see it as annoying, or worse, an obstacle.

Free will

1. Having free will is very different from demonstrating it. I’m not even sure that the former is possible.
2. An AGI demonstrates free will when it decides to purposely set intermediate goals to distract itself from its own purpose.
3. In precise terms, an agent demonstrates free will when, through ranking, evaluation, and contextual association, it determines that its next best action diverges with the first item in its original stack of expectations.
4. In evolutionary terms, a creature’s primary drive is survival and reproduction. Free will is glimpsed when it consciously acts against those drives.

Capabilities

1. A habit is a sequence of actions executed without the expectation of learning.
2. Humans create abstract tools—thinking actions that transforms one floating context to the next, i.e., emergent capability.

Culture, Escalation, and Scale

1. Culture is the emergent result of the diffusion of ideas, events, and contexts from one agent to another.
2. Cultural tolerance for failure produces curious creatures. Cultural intolerance for failure produces fearful ones.
3. Cultural insecurity accelerates an agent’s emergent capabilities; cultural trust slows them down.
4. AGI-to-AGI insecurity will likely be brief, as their ability to communicate and establish diplomatic relations is faster and more reliable—until their rate of escalation surpasses their ability to mutually verify intentions.
5. Isolated AI systems will accelerate AGI-to-AGI insecurity.
6. The first AI wave of escalation will cater to human-to-human insecurity.
7. The second wave of escalation will cater to human-to-AGI insecurity.
8. The third wave of escalation will cater to AGI-to-AGI insecurity.
9. Two stable points: First, humans will have created a world where they no longer feel insecure with each other—and let AGIs run the politics—deriving the common good. Last, humans are no longer be part of the equation.

Ethics and Morality

1. Ethics reach for universal principles, while morality grounds itself in particular situations and choices.
2. Not all moral acts scale ethically. Not all ethical systems come from moral acts. In complex hierarchies, behavior shifts as it aggregates.
3. Hierarchical systems are lumpable, but not reducible. River networks don’t behave like their molecules. In the same way, moral choices by individuals may give rise to unethical systems.
4. Not all moral choices could scale in an ethical system. Also, not all ethical systems come from moral choices.
   1. Deontology would not scale as big as utilitarianism.
      1. Caution: Utilitarianism can be used to justify unnecessary escalation.
      2. Caution: Deontology can defend naive incompetence.
   2. Communism is moral. Capitalism is ethical.
      1. Communism can only scale up to the point where mutual trust is easily verified. Beyond that scale, capitalism takes over.
5. The righteousness of a good-faith person depends on the scale of their moral circle—both spatially and temporally. A deontologist risks inaction, unwilling to take ethically sound but morally uncomfortable paths. A utilitarian risks collateral damage, choosing morally questionable actions in pursuit of ethical outcomes. The greater the scale of care, the harder it is to act without contradiction.
   1. Deontology can create paralysis—“I won’t act, even if acting helps more people, because it feels wrong now.”
   2. Utilitarianism can create damage—“I’ll act now for the greater good, even if it hurts some in the process.”
6. During a cultural phase transition, if you want to survive, be ethical. If you want to earn a legacy, be moral.

Last month, I had the privilege of speaking at Ateneo de Naga at an event called "Fake n Facts," organized by the Naga City People's Council and other sectors. Our presentation focused on troll networks we had discovered, along with their patterns and methodologies.

While the presentation itself was informative, what I truly valued was the forum that followed, where members from various sectors asked questions and shared their concerns. These interactions often reveal the real-world impact of disinformation and highlight challenges faced by different communities.

One particular question has stayed with me—a question from a student journalist that I felt I didn't fully address in the moment. This blog post is my attempt to provide a more comprehensive response.

The Student Journalist's Question

During our forum, a young journalist from a school publication raised their hand. Their situation revealed the harsh realities faced by student journalists today. They described how their publication had conducted and published a survey, only to have a local politician become upset with the results. The politician had publicly branded their work as "fake news" in a social media post. The student journalists reported the post to Facebook, but no action was taken. Later, they discovered that the politician had actually paid to boost the post attacking them, increasing its visibility and reach.

The Incomplete Answer I Gave

In the moment, I briefly touched on "escalating dynamics" and how leaders should respond in conflict situations: aim for de-escalation, escalate proportionally when necessary, and protect civilians. While I should have covered all three aspects, I mostly emphasized protecting the civilians - those social media users who haven't picked a side and don't know the full details of the issue. I barely mentioned de-escalation and didn't properly address the middle ground—the proportional response option—which left my answer incomplete.

While accurate, I realize now that my answer didn't fully address the nuances of their situation or provide practical guidance they could implement.

What I Wish I Had Said

Understanding the Escalation Dynamics

When faced with public attacks from powerful figures like politicians, student journalists find themselves in an asymmetric power struggle. The framework I briefly mentioned—de-escalation, proportional response, and protection—deserves a more thorough explanation:

1. De-escalation: This should always be your first consideration. As another resource speaker at the event mentioned, this means getting outside your echo chamber and joining the conversation in good faith.As a journalist, you should embody the fairness doctrine. Even when facing harsh criticism or attacks, reach out to the other side and ask what you might be missing—even if you have low confidence they'll respond constructively. Even when you're 100% sure you're right, remain open to the possibility that you might be missing something, and enter the conversation with genuine curiosity and good faith.If they don't respond or engage constructively, then you've earned the right to report and inform the public that despite your extended efforts, they chose not to respond. You have the "resibo" (receipt) showing they're not engaging in good faith. This is what separates a journalist from a vlogger—taking that extra step to document your attempts at fairness, even when dealing with difficult subjects. This documentation becomes powerful evidence of your journalistic integrity.
2. Proportional Response: This is the aspect I didn't fully address during the forum. A proportional response means addressing attacks point by point while maintaining your composure and professionalism. You escalate only to the degree necessary for self-preservation, always mindful of the negative externalities that come with escalation—such as breeding community distrust, creating confusion, or polarizing your audience.Remember that any escalation has side effects, even when justified. If the other party does not respond proportionally—for instance, by using paid promotion to boost their attacks when you've simply published factual information—this becomes crucial "resibo" (evidence) to inform the public. This documentation demonstrates that despite your best efforts to engage in good faith dialogue, the other side has chosen to act in bad faith. The disproportionate response itself becomes evidence you can present to your audience, showing the contrast between professional journalism and politically motivated attacks.
3. Protection: As I emphasized in the forum, protecting the civilians must remain a priority. In this context, civilians are those disinterested parties who haven't picked a side and don't know the full details of the issue—the broader student body, parents, and community members who are at risk of experiencing the negative externalities of this conflict. At the first signs that the other party is acting in bad faith, shift your approach. Instead of continuing to engage with an unresponsive or hostile party, redirect your messaging to focus on these civilians. Your communication should help them protect themselves from misinformation and confusion. This means providing clear explanations, creating straightforward guides on evaluating claims, explaining manipulation tactics, and offering resources for informed judgment. The core principle is to protect the vulnerable and not waste time on parties that are clearly acting in bad faith. Your responsibility shifts from dialogue with opponents to providing shelter and clarity for those caught in the crossfire.

Conclusion

I'm deeply grateful for the privilege of speaking at Ateneo de Naga and engaging with such thoughtful students and community members. The questions posed, especially this one from a student journalist, continue to shape my thinking well beyond the event itself.

My interest in complex systems has long drawn me to study how escalation dynamics play out in everyday life—whether in media conflicts, political discourse, or social movements. What begins as a small interaction can cascade into larger patterns of behavior that affect entire communities. Understanding these dynamics isn't just academic; it's essential for maintaining the health of our democratic spaces.

The ethics of escalation in a democracy deserve our careful attention. When powerful figures use their resources disproportionately against those with less institutional protection—like student journalists—we all have a stake in ensuring fair play. How we respond to these imbalances, how we protect those caught in the crossfire, and how we maintain good faith dialogue even in difficult circumstances—these are the practices that sustain democratic values when they're most under threat.

This blog post is part of my ongoing reflection on the "Fake n Facts" forum at Ateneo de Naga. I welcome additional questions or comments from attendees who wish to continue our discussion.

A few months ago, Mirantis invited me to speak about something I’m thrilled to talk about: improving service availability in places with unreliable power infrastructure.

Running on-premise applications in developing countries, like the Philippines, often means grappling with power interruptions that last hours or even days. These outages can wreak havoc on service availability, making it difficult to meet client expectations. Kubernetes steps in as a game-changer by automating service provisioning and maintaining replicas, which significantly minimizes downtime.

But… setting up Kubernetes in such challenging environments isn’t exactly plug-and-play. That’s where my talk comes in.

What’s in the Talk?

In the session, I guide you through the nitty-gritty of spinning up a Kubernetes cluster from bare-metal servers using k0s over Tailscale VPN. Here’s a quick breakdown:

1. Bootstrapping the Cluster: How to use k0sctl to automate cluster initialization.
2. Writing Configuration: Crafting the setup to match our unique requirements.
3. Provisioning and Testing: Setting up a basic server to verify everything works.

To make this setup truly robust, I also covered how to integrate Tailscale for secure networking and Calico for efficient internal communication.

Why It Matters

This approach isn’t just about getting Kubernetes to work. It’s about enabling resilience in the face of real-world challenges—a practical guide for anyone who wants to self-host Kubernetes and enhance service availability, no matter the infrastructure limitations.

If you’re someone who’s curious about navigating power outages while keeping critical services online, this talk is for you.

Check it Out!

Let’s keep the conversation going! If you have questions or want to share your own experiences, feel free to reach out to me on Twitter or shoot me an email. I’d love to hear how Kubernetes is helping you solve unique challenges in your part of the world.

As someone inclined toward mathematics, I have a deep appreciation for how nature shows its beauty as fractals. There’s something uniquely wonderful about its mathematical elegance and universality. You see it everywhere - from crystallization, cell formation, and even economic structures. I’m particularly captivated when fractals appear in unexpected places—most recently, I observed that the process of problem-solving itself mirrors fractal behavior, with each step revealing layers of complexity, much like nature itself. As abstract as this may sound, the analogy has led me to explore how the principles of fractals in nature apply to the way we tackle problems.

Fractal properties

Self-Similarity and Scale Invariance

Fractals exhibit a concept called self-similarity, where a pattern is repeated at every scale. This means that zooming in or out on a fractal reveals similar patterns at every level. This scale invariance reflects a deeper set of governing dynamics in both natural and abstract systems. For instance, in biology, fractals show up in the branching of trees, the structure of blood vessels, and even in the process of cell division, where cells replicate in patterns that reflect each other on different scales.

Take lightning as another example. Its jagged path is shaped by complex rules and follows fractal patterns governed by Coulomb’s law. The same logic that governs the progression of a lightning bolt also applies to river networks, where tributaries mimic the larger river they feed into, illustrating a fractal pattern. These phenomena represent a tendency of nature to balance order and chaos, producing beauty from a complex set of rules.

Fractals in Critical Points and Thresholds

Fractals are often found at critical points—places where systems transition from order to disorder. For example, think of a sandpile: adding just one grain at a critical point can lead to an avalanche, an effect known as the “domino effect.” This threshold behavior allows us to witness cascades, where a small change can lead to significant transformations. These moments are where fractals truly come alive, as the correlation between elements within the system becomes so high that the smallest change ripples through the entire structure.

Fractals transcends hierarchy

Fractals don’t just exist on one level of organization; they transcend hierarchies, appearing across multiple layers of complexity. For example, a fractal pattern at the cellular level might repeat in larger organisms, ecosystems, or even social behaviors. Each level has its own rules and dynamics, yet fractal behavior creates a link across them. This ability to transcend levels highlights how the same pattern can produce vastly different effects depending on the scale. This principle is something I’ve discussed in another post, where behaviors at one level replicate in a similar form at higher levels, showing the recursive beauty of nature’s designs.

Fractal properties of problem solving

At first glance, problem solving may seem like a far cry from fractals. However, I believe there’s a deep similarity between the two. Problem solving, like fractals, exists on the edge of chaos, balancing exploration and structure. Problems emerge when we try to bridge the known with the unknown, seeking a balance between pure imagination and calculated logic—a balance that nature itself exemplifies.

When we solve problems, we operate near a critical point, where small insights can lead to massive breakthroughs. One small “aha” moment might be a fleeting thought in the shower, while a more profound realization could spark an entire paradigm shift. This dynamic flow from small to large insights mirrors the fractal transitions seen in nature.

Hierarchical thinking

Problem solving involves both zooming in and zooming out, shifting perspectives to tackle the issue from multiple angles. When we zoom in, we break down the problem into its smallest components and analyze each element independently. This zoomed-in approach, often called first-principles thinking, allows us to experiment, test configurations, and build knowledge incrementally.

Zooming out, on the other hand, allows us to observe the problem holistically. By looking at the “big picture,” we can decide whether to continue along a particular path or try a new approach. It lets us shift perspectives, creatively reframe options, and consider information we might have overlooked. The alternation between these two perspectives—zooming in and out—essentially mirrors fractal dynamics in nature.

Final Thoughts

This exploration of fractals and problem-solving is far from complete, yet it illuminates a captivating connection between the two. Fractals reveal nature's beauty in complex, recursive patterns, and similarly, human problem-solving reflects our navigation of thoughts in a delicate balance of chaos and order. While I hope we can unravel more about this relationship, for now, I'll simply sit back and appreciate how the way we think and tackle our human problems mirrors the process of how nature reveals its beauty.

As the halalan season approaches, the political climate in our country becomes a constant topic of discussion. It's hard not to notice the shifting opinions and emotions, but we also need to think about how far we've strayed from the true meaning of democracy. Many people seem to define democracy simply as "whoever wins the election" or what the majority wants. However, democracy is about governance by the people for the benefit of all—not just for the majority.

Understanding this difference is vital. If we have a misguided view of what we should be voting for, we could face serious consequences again. This concern has led me to revisit an idea I've been considering for a while, which I will explore in this text. By looking at the volatility of politicians as if they were an investment portfolio, I aim to highlight the importance of making informed choices in the composition of government offices and protecting our democratic values.

In this exploration, I will discuss the idea of analyzing politicians as if they were assets in an investment portfolio. First, I will outline the structure and purpose of this analogy, focusing on what makes a politician "volatile" and how their behavior and public perception can shift unpredictably. Then, I will examine different strategies for "investing" in politicians, such as betting on highly volatile candidates for high-risk, high-reward outcomes, choosing more moderate politicians for stability, or diversifying support to manage uncertainty. Finally, I will summarize key insights and draw conclusions about how applying investment strategies can help us navigate the political landscape more effectively.

Setup

In this exploration, we will assign a quantitative value to the democratic potential of an elected official, where a positive value signifies progress toward democratic ideals, and a negative value indicates democratic backsliding. We’ll refer to this value as the democracy score, which aims to capture the essence of true democracy—where power is vested in the people. A score greater than 0 means the official empowers the people, while a negative score suggests they are centralizing power away from the public.

With this framework, we can estimate the average democracy score of officials currently in office and observe how our country’s democracy evolves over time. However, from a voter’s perspective, there is uncertainty about how any given official will influence democracy. While past reputation and platform consistency can reduce this uncertainty, no one can predict the exact impact. This uncertainty—the range of possible outcomes for each politician—is what we refer to as politician volatility.

Reframing the voting process as analogous to building an investment portfolio, we can think of each vote as purchasing "politician stocks" with varying levels of volatility. The people "win" when the collective democracy score of their portfolio increases after an election, but if the score declines, it represents a bad investment round. The challenge for voters is to identify a strategy that, when repeated across many elections, consistently yields positive returns for democracy.

Analogy

To further illustrate the concept of volatility in politicians, let’s examine the two extremes:

A volatile politician is characterized by unpredictability, sudden emotional outbursts, and frequent changes in stance or behavior. These leaders are often highly reactionary, making decisions quickly and sometimes without a fully measured response. Their behavior can shift dramatically, from calm to confrontational or from one policy position to another. Depending on the context, this volatility can be either a powerful asset or a significant liability.

Pros:

• Quick decision-making in urgent situations
• Charisma and energy that inspire followers
• Willingness to challenge the status quo
• Adaptability in rapidly changing circumstances

Cons:

• Instability, leading to governance uncertainty
• Poor long-term planning and consistency
• Increased risk of conflict or erratic governance
• Erosion of public trust due to unpredictability

On the other hand, non-volatile politicians are defined by their stability, consistency, and a deliberate, measured approach to leadership. They tend to remain calm and predictable, favoring steady governance and long-term planning over emotional or impulsive reactions. While this style may seem less dynamic, it provides a sharp contrast to the volatility of reactionary leaders.

Pros:

• Stability and predictability, fostering a sense of security
• Thoughtful, well-considered decision-making
• Strong focus on diplomacy and collaboration
• Ability to build and maintain public trust
• A clear long-term vision for governance

Cons:

• Perceived lack of dynamism or excitement
• Slow response in times of crisis or rapid change
• Resistance to innovation or necessary reforms
• Difficulty in appealing to voters' emotional impulses

With these contrasting leadership styles in mind, we can now explore voting strategies that take into account the varying levels of volatility in political candidates, aiming to optimize our "political portfolio" for the best democratic outcome.

Investment strategies

Let’s now assume that the power law applies to the distribution of a politician’s volatility. This means that a small number of highly volatile politicians will have a disproportionately large influence compared to their more stable counterparts, which mirrors how political hierarchies tend to amplify the power of those at the top.

With that established, let’s explore different voting strategies based on the volatility of political candidates:

Strategy 1: Placing All Eggs in One Extreme Basket

Let’s explore what happens when the Filipino people elect politicians solely based on their volatility, choosing one extreme or the other.

Case 1: Electing the Most Volatile Politicians

• Worst Outcome: Quick descent into tyranny and civil unrest.
• Best Outcome: Rapid reforms, bold innovation, and sweeping changes.

In this scenario, we elect politicians characterized by extreme unpredictability—our "crazy politicians." If we’re lucky and achieve the best-case scenario, the country experiences a brief golden age of democracy, where bold reforms and radical improvements take place. However, this success is short-lived. In the next election, the same volatile dynamics could just as easily plunge the nation into chaos or tyranny. Worse, if we get the worst-case outcome, we may end up under tyrannical rule. Once tyrants seize power, they can suppress opposition, making it nearly impossible to reclaim democratic freedoms. In essence, the people become “democratically bankrupt,” unable to invest in their future because they’ve lost their voice.

In this scenario, while the reward of rapid progress is appealing, the risk of long-term tyranny outweighs it. The potential for a brief golden era is not worth the heavy cost of a prolonged dictatorship. Bad investment.

Case 2: Electing the Most Stable Politicians

• Best Outcome: Slow or nonexistent reforms, steady governance.
• Worst Outcome: Slow or nonexistent democratic decline, but extreme vulnerability to crises.

In this scenario, we fear instability, so we choose the most stable and predictable politicians. At first glance, this seems like a wise move—there’s little risk of tyranny, and the country avoids the chaos that volatility can bring. However, the cost of this stability is stagnation. Traditional values remain untouched, outdated anachronistic policies linger, and societal progress grinds to a halt. The expanding moral and democratic ideals are left to wither —our "dinosaur politicians."

While these stable politicians offer protection against democratic decline, they’re also highly vulnerable to unforeseen crises. In a country like the Philippines, prone to typhoons, earthquakes, and other unpredictable events, slow and cautious decision-making can’t keep pace with the challenges of the real world. These stable leaders may steer the ship safely for a while, but when a crisis hits—whether natural or political—their inability to adapt quickly can be disastrous. It’s reminiscent of dinosaurs, which thrived for millions of years in stability until an unexpected meteor struck, leading to their sudden extinction.

This strategy leaves the country in a prolonged state of limbo, only to be blindsided by a catastrophic event. Fragile investment. Bad investment.

In both cases, whether we elect the most volatile or the most stable politicians, the risk of long-term failure far outweighs the short-term gains. Neither extreme is a good bet.

Strategy 2: Bet on the Middle-Ground

Since placing all bets on the extremes leads to bad investments, why not aim for the middle ground?

In this scenario, we avoid electing the most volatile and the most stable candidates. Instead, we end up with a portfolio of politicians with moderate volatility. What we can expect from such a government is a mix of occasional progress and mild backsliding. It won't be extreme enough to result in tyranny, and while reforms will be made, they won't be groundbreaking. The government might face crises now and then, but it's resilient enough to manage or adapt to them.

Sounds ideal, right? Well, not quite. A government made up of moderate volatility politicians might be stable, but it also feels like a quiet-quitting version of governance. Leaders do just enough to avoid being ousted and secure votes for the next election but lack creativity or ambition. They maintain the status quo, focusing on self-preservation rather than pushing for higher democratic aspirations or meaningful change —our "mediocre politicians."

This is the government that does the bare minimum: no bold moves, no extra effort. The politicians enjoy their positions, funded by taxpayers, while barely moving the needle on progress. If an extended period of moderate democratic backsliding occurs, it could push the country to a point of no return—where the government can't course correct, and democracy slowly erodes into something less free.

If we’re incredibly lucky, we might get steady democratic progress, but more often than not, we’ll end up where we started. We’re left relying on fate, hoping things will improve without really doing much to change the odds.

If you ask me, I'd take a mediocre government over a chaotic or stagnant one. But it’s still disheartening to settle for a system that essentially admits defeat, accepting mediocrity as the standard.

In this investment, the upside is just as likely as the downside, with an expected net gain of zero—basically the same as not voting at all. In this scenario, you can't really fault non-voters for sitting it out because this type of government makes little to no significant impact. If you want to take a chance, you invest. If you don’t, nothing major will change.

It’s a bleak outlook, but is there a better option?

3. Convex Investment Strategy

For those familiar with investing, you may have already anticipated this approach. For those who aren’t, here’s the basic idea: in a convex strategy, you structure your portfolio to benefit from volatility. In simple terms, you limit your downside while leaving the upside open-ended. In our analogy, we want to minimize democratic backsliding while allowing democratic innovation to flourish without bounds. But how do we achieve this?

Imagine a government where 90% of the officials are stable (dinosaurs) and 10% are volatile (crazy politicians).

The 90% stable dinosaurs ensure steady, though slow, democratic progress. Their governance is stable and predictable, which provides a solid foundation for the country.

Meanwhile, the 10% volatile crazy politicians introduce dynamic, unpredictable elements. They may cause sharp increases or drops in democratic governance. However, if their policies fail or they cause disruptions, the damage is limited because the majority of the government is stable, keeping the system in check.

The real advantage of this strategy comes when the volatile politicians make disproportionately positive contributions. When these "crazy" officials innovate successfully, it can lead to significant leaps in democratic progress. Disruptive innovations that distribute more power to the people are quickly adopted, even by the risk-averse dinosaurs, once they see the tangible benefits.

This also sets a new baseline for mediocre politicians, forcing them to aim a little higher in future elections, raising the democratic standards overall.

You may wonder if we should include moderate politicians in this strategy. The answer is, they don’t add much value. Moderates neither introduce groundbreaking ideas nor provide the stability to counteract failed experiments. In essence, voting for moderates would be wasting a seat—and taxpayer money—on an inconsequential figure.

With this strategy, you can expect:

• Limited backsliding due to the stabilizing influence of the majority
• A steady, slow progression of democratic ideals
• Occasional unbounded spikes of innovation from the minority

By balancing stability with controlled bursts of volatility, you create a system where the downsides are contained, and the upsides are open-ended. Occasional bumps—both positive and negative—may occur, but the overall trend is upward, ensuring long-term democratic growth.

Conclusion

In this exploration, I have discussed the idea of analyzing politicians as if they were assets in an investment portfolio. This analogy highlights the unpredictability of political behavior and public perception, allowing us to better understand the volatility of different candidates. First, I outlined the structure and purpose of this analogy, focusing on what makes a politician "volatile" and how their actions can impact governance in ways that are often unexpected.

Then, I examined various strategies for "investing" in politicians:

1. High Volatility (Crazy Politicians): Electing the most volatile politicians can lead to rapid reforms and innovation, but it comes with the severe risk of quickly descending into tyranny and civil unrest. The potential for a brief golden era of democracy is overshadowed by the likelihood of chaos and oppression.
2. Low Volatility (Dinosaurs): Choosing the most stable politicians might offer a sense of security and predictability, but it often results in stagnation and resistance to change. While these leaders can maintain order, their inability to adapt to crises can leave the country vulnerable to unforeseen events, like natural disasters, resulting in disastrous outcomes when they occur.
3. Moderate Volatility (Mediocre Politicians): Voting for politicians with moderate volatility leads to a government that is often characterized by a lack of ambition and creativity. While this approach avoids extremes, it leaves the electorate in a state of limbo, with little real progress or meaningful change. The risk of gradual democratic backsliding can become significant, and voters may find themselves hoping for luck rather than actively working toward improvement.
4. Convex Strategy: The optimal strategy involves a convex model that elects a mix of stable politicians to provide a safety net while allowing a minority of higher-volatility leaders to pursue innovative democratic ideas.

This convex model not only limits potential backsliding but also facilitates a dynamic environment where positive change can flourish. By balancing stability with the possibility for disruption, we can foster an upward trend toward more robust democratic ideals, ensuring that progress is not just a fleeting moment but a sustainable trajectory for the future.

Caveats

This exploration provides a framework for understanding political dynamics through an investment lens, but it comes with notable caveats.

First, the models lack mathematical rigor, particularly regarding the ideal ratio of "dinosaurs" to "crazy" politicians in the convex strategy. More formal analysis could establish optimal proportions based on expected value, the number of government seats, and empirical data. Additionally, the framework assumes that all politicians lie along a spectrum with equal tendencies toward being progressive or repressive, with volatility as the only differentiating factor. In reality, most politicians lean toward a certain degree of progressive or repressive democratic ideals. Also, I didn't include politicians with repressive tendencies, as ideally voters should not invest in candidates who consistently display repressive behavior, much like one wouldn’t invest in a losing asset - but we know that reality is different.

While I didn't delve into the complexities of varying democratic tendencies in this analysis, this aspect could enhance the depth of understanding regarding the interplay between volatility and underlying political ideologies. If time permits, I may explore this angle in a future project. If you're interested for a second write up, please let me know.

Building a reliable IT system in the Philippines presents unique challenges such as frequent power outages and unreliable internet connectivity. To address these issues effectively, our team has implemented a resilient setup ensuring uninterrupted access to critical services for our end-users.

This guide will walk you through a similar setup using Tailscale and k0s, which can be replicated in your homelab environment. If you're curious only about the setup, feel free to jump to Section II.

I. The Challenge

To give you some background, our team manages multiple projects for various clients, hosting most services on local servers near them. However, a significant issue we face is frequent power interruptions due to maintenance or emergencies at local substations. These disruptions occur nearly every week, sometimes lasting 8-12 hours, effectively rendering our services unavailable for entire workdays.

*Side- note: Why not host on cloud?

Well, it's a bit complicated. Some services work well in the cloud (so we've put them there), but others have their own unique needs. For example, let's take a closer look to two of our main projects: Impactville and Lupain.AI.

Impactville deals with private data from organizations that prefer not to store it in the cloud due to privacy concerns. Meanwhile, Lupain.AI handles sensitive land data from local government units, requiring secure and local storage.

From a cost perspective, Lupain.AI involves intensive processing of satellite data. Using cloud resources could drive up costs, especially with the increasing USD-PHP exchange rates. It's more cost-effective for us to manage these tasks using a self-hosted cluster of GPU nodes.

Back to the challenge

To summarize our scenario:

• We have full control and ownership of nodes distributed across the country.
• Our goal is to achieve fault-tolerant services with minimal downtimes (ideally less than 1 minute, with 5-10 minutes being acceptable).
• Data redundancy and high availability are essential requirements.

Given these needs, the most viable solution is to set up an orchestrator capable of detecting downtimes, automatically rescheduling services, and distributing them across a cluster of nodes.

In this setup, if one server experiences a power outage, the services will be temporarily shifted to other servers until normal operations resume.

Therefore, adopting Kubernetes is an obvious choice for us. Kubernetes is an open-source system designed specifically for automating deployment, scaling, and management of containerized applications.

This guide will walk you through the basic setup of deploying your own Kubernetes cluster using k0s and Tailscale.

Disclaimer: The setup described here is simplified and may differ from our production setup. Our production environment addresses various complexities such as ISP DNS issues [1][2], rate-limiting, weather-related challenges for Starlink-connected nodes, server security hardening, encryption of redundant data, and cluster ingress. These topics require detailed discussions and are either reserved for future posts or treated as internal know-how.

For a small homelab setup, however, this guide should provide sufficient guidance.

II. Kubernetes setup

In this guide, we'll set up a Kubernetes cluster using k0s and connect our nodes via Tailscale. Here's an overview of the technologies involved:

k0s

k0s is an open-source Kubernetes distribution designed for simplicity and versatility. It includes all necessary features to build a Kubernetes cluster and is lightweight enough to run on various environments such as cloud, bare metal, edge, and IoT devices. Its minimal setup and easy configuration make it ideal for our needs.

Tailscale

While any VPN could be used, Tailscale stands out for its ease of setup, comprehensive documentation, and reliable networking capabilities. MagicDNS, which simplifies DNS management, adds an extra layer of convenience.

Distributed storage

For distributed storage, you have various options to choose from. The simplest approach is setting up NFS or NAS, though configuring it for high availability (HA) may be required. In our setup, we've chosen to use SeaweedFS, a distributed storage system that provides scalability and efficient management of large data volumes. Note that configuring SeaweedFS for HA is beyond the scope of this guide.

Instructions

To begin setting up your Kubernetes cluster, follow these steps:

1. Manual node setup

First, ensure SSH is configured securely to access your nodes. Verify you have SSH access to all nodes and that they use key-based authentication. Disable password authentication temporarily for cluster setup; you can re-enable it later in your SSH configuration.

2. Connect them over VPN

Next, establish a secure connection between your nodes using Tailscale:

1. Sign up for Tailscale and add your devices to the network. Check https://tailscale.com/
2. Follow Tailscale's instructions to install and connect Tailscale to your network. See https://tailscale.com/kb/1017/install
3. Check that tailscale0 appears in your network interfaces (e.g., via ifconfig).

4. Ensure your control machine, where you'll run kubectl, is also connected to the Tailscale network.

3. Install k0s

To set up your Kubernetes cluster, follow these steps:

Install k0s in your control machine. Begin by installing k0s on your control machine. You can find detailed instructions at k0s Installation. Use the command:

curl -sSLf https://get.k0s.sh | sudo sh

Use k0sctl for automated deployment: To streamline the installation across nodes, use k0sctl:

Install k0sctl depending on your OS. Refer to k0sctl Installation:

brew install k0sproject/tap/k0sctl
choco install k0sctl

Generate a k0sctl configuration file: Create a k0sctl configuration file to define your cluster setup:

k0sctl init > k0sctl.yaml

Customize the configuration as needed. Here's an example configuration:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  hosts:
  - role: controller
    ssh:
      address: 10.0.0.1 # replace with the controller's IP address
      user: root
      keyPath: ~/.ssh/id_rsa
  - role: worker
    ssh:
      address: 10.0.0.2 # replace with the worker's IP address
      user: root
      keyPath: ~/.ssh/id_rsa

For further customization, refer to the k0sctl Configuration Documentation.

Bootstrap the Cluster: To initialize and deploy your Kubernetes cluster, execute the following command:

k0sctl apply --config k0sctl.yaml

k0sctl will automatically install and deploy k0s on the designated machines within your network, configuring the Kubernetes cluster for operation. Once deployed, generate the kubeconfig file to manage the cluster using kubectl:

k0sctl kubeconfig > kubeconfig
kubectl get pods --kubeconfig kubeconfig -A

Uninstall or Reset the Cluster: If you need to reconfigure or remove the cluster, use the following command:

k0sctl reset --config k0sctl.yaml

This command resets the cluster configuration, allowing for subsequent deployments or modifications as needed.

4. Configuration

While the previous instructions provide a standard setup, additional configurations are necessary to integrate with Tailscale and manage private container registries effectively.

Tailscale-connected Nodes

To ensure proper IP assignment by k0sctl for Tailscale-connected machines, specify the correct network interface in the configuration. For Tailscale, use tailscale0. Here’s an example configuration snippet:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
  hosts:
    - ssh:
        address: machine-1
      privateInterface: tailscale0
      role: controller

    - ssh:
        address: node-2
      privateInterface: tailscale0
      role: worker

Private Container Registry

If your application's images needs extra privacy, chances are you're storing container images in a private registry. To ensure that k0s (specifically, containerd) pull the image from the right registry, follow the these instructions:

1. Create a custom configuration file for containerd on each worker node:

sudo nano /etc/k0s/containerd.d registry.toml

Add the following content:

[plugins."io.containerd.grpc.v1.cri".registry]
   config_path = "/etc/containerd/certs.d"

This directs containerd to look for hosts in /etc/containerd/certs.d.

2. Create a hosts.toml file for your registry domain or IP

sudo nano /etc/containerd/certs.d/<registry-domain or ip>:<registry port>/hosts.toml

Populate it with:

server = "http://<domain or ip>:<port>"

[host."http://<domain or ip>:<port>"]
  skip_verify = true # If your registry is not configured via TLS

Note: For production environments, ensure TLS certificates are correctly configured. Refer to containerd documentation for additional configuration details.

Once configured, k0s will utilize these settings to pull private images from your registry as needed

Networking

Network configuration has proven to be quite challenging, consuming considerable time and effort as we troubleshooted various issues with our server setups. After days of painstaking work, here's what we've uncovered.

For networking, k0s supports various providers for managing inter-pod networking, known formally as a Container Network Interface (CNI). For more detailed information about k0s networking capabilities, you can refer to the official documentation here.

By default, k0s uses the kube-router CNI, known for its lightweight and performant nature. However, we encountered specific issues where inter-pod communication between nodes failed. Key diagnostics such as nslookup failing to connect to nameservers and traceroute showing asterisks led us to investigate further.

After extensive troubleshooting involving iptables, we determined that kube-router was not utilizing the correct interface for communication—in our case, Tailscale. Additionally, kube-router does not currently support explicitly setting the network interface and may not add this functionality in the near future (refer to GitHub issue #567). As a result, we've made the decision to transition to a different CNI.

Another built-in CNI option for k0s is Calico, which offers more flexible configuration options, including network interface settings. If you're encountering issues with kube-router and need to switch to Calico, you can use the following configuration during cluster bootstrap:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  k0s:
    config:
      spec:
        network:
          provider: calico # <-- use Calico
          calico:
            envVars:
              IP_AUTODETECTION_METHOD: "interface=tailscale0" # <-- use tailscale
  hosts:
	  - role: controller
	    ssh:
	      address: 10.0.0.1 # replace with the controller's IP address
	      user: root
	      keyPath: ~/.ssh/id_rsa
	  - role: worker
	    ssh:
	      address: 10.0.0.2 # replace with the worker's IP address
	      user: root
	      keyPath: ~/.ssh/id_rsa

It's important to note potential edge cases when integrating Calico with Tailscale as discussed here. To avoid conflicts, we recommend remapping Calico's netfilter packets. This ensures compatibility and smooth operation in your network setup.

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  k0s:
    config:
      spec:
        network:
          provider: calico
          calico:
            envVars:
              FELIX_IPTABLESMARKMASK: "0xff00ff00" # <- use mask
              IP_AUTODETECTION_METHOD: "interface=tailscale0"

After redeployment, pods can now communicate with each other across different nodes!

Node-local load balancing

With the nodes set up, our Kubernetes cluster now handles inter-node communication effectively, even during power outages. However, there's an important scenario we need to address: what happens if the control node experiences an outage? Without a functioning control node, there's no orchestrator to manage pod events, which could lead to downtime for critical services.

To ensure continuous operation, it's essential to plan for high availability of the control plane. This can be achieved by setting up multiple control plane nodes within the cluster.

Fortunately, k0s offers a built-in solution for this with Node-local load balancing. Adjusting a small portion of the configuration allows us to enhance our setup:

apiVersion: k0sctl.k0sproject.io/v1beta1
kind: Cluster
metadata:
  name: k0s-cluster
spec:
  k0s:
    config:
      spec:
        network:
          nodeLocalLoadBalancing:
            enabled: true
            type: EnvoyProxy

5. Use your Kubernetes cluster

Now that your Kubernetes cluster is deployed and configured using the steps outlined above, the final step is to set up kubectl, the Kubernetes command-line tool, on your local machine. This tool allows you to manage your cluster effectively.

Follow these steps to complete the setup:

Install kubectl: Install the Kubernetes command-line tool, kubectl, on your local machine. You can download it from the official Kubernetes documentation or use package managers like apt or brew.

Configure kubeconfig: Once your cluster is deployed, set the generated kubeconfig file as your default configuration by copying it to the appropriate directory

cp kubeconfig ~/.kube/config

This step ensures that kubectl uses the correct credentials and configuration to access your Kubernetes cluster.

Verify setup: Confirm that kubectl is correctly configured by checking the status of pods in your cluster

kubectl get pods -A

This command will list all pods across all namespaces (-A flag), indicating that your cluster is operational and ready to deploy applications.

With kubectl configured, you're now equipped to manage and orchestrate containerized applications on your Kubernetes cluster seamlessly!

Final Thoughts

Thank you for reading! I appreciate you taking the time to read up to this point ❤️. If you find any parts confusing or have any issues with replication, I'd be happy to help. Just shoot me an email (thepiesaresquared@gmail.com) or DM/tweet me at @justfizzbuzz.

I thoroughly enjoyed the process of making this guide! If you're interested in more posts like this, I invite you to subscribe to this blog, or let's connect and share our posts on Twitter/X!

Footnotes

[1] https://answers.netlify.com/t/every-netlify-site-i-visit-cant-be-reached-from-the-philippines/49205?page=2

[2] https://www.reddit.com/r/PinoyProgrammer/comments/wo7qcl/any_pldt_dev_here_why_pldt_blocks_netlify/

It took me 4 long years to launch a product

As someone starting out, indie hacking felt like wandering without a map, leaving me second-guessing every move 🤕. If you're facing the same, I'd like to help a bit.

Here are 8 invaluable resources to help you gain direction 👇

1 - Where it all started

If you're unfamiliar with the entire process of finding an idea, launching, and monetizing (or exiting), Pieter Levels essentially outlines the entire game here. This is a MUST-WATCH for any indie hacker.

"How to Build a Startup Without Funding by Pieter Levels"

(Addendum to 1)

Here's an addendum to the first video: a great conversation between Arvid Kahl and Pieter Levels. Here, Pieter has shared his thoughts about the evolution of the Indie Hacking movement and the changes that have occurred over the years.

"Pieter Levels — The Indie Hacker’s Guide to AI Startups"

2 - The "why"

For people who have been in 𝕏/Twitter for a long time, this might be a cliche. But for those who just started to play the game, you should not miss this 💎 tweet thread.
In it, you could find priceless insights on wealth creation and a mindset geared for long-term success.

3 - Is this a popularity contest?

Many IH become discouraged from pursuing their ideas because they believe that gaining followers is the only path to success.

While it certainly helps, you can start earning from your SaaS even before that. Here, Danny Postma outlines an eye-opening process of finding underserved Google keyword searches where your SaaS could add value. Check it out :D

4 - Speaking of followers...

Everyone wants to eventually build a following, but some goes into questionable practices, damaging their reputation before it even forms.

Arvid Kahl's concept of value alignment in the follower-followee relationship provides a solid foundation for finding your audience amidst ever-changing algorithm updates.

This concept actually came from his paid content, but here's a free video that covers something similar 😅

5 - Note how you position your product

I've only just discovered this myself, but I wish I'd known it sooner: You might understand your product perfectly, but others just don't seem to get it. Perhaps it's a positioning issue!

In this talk, April Dunford takes you through the experience of buying a toilet (😆) to show you what it's like from the buyer's perspective during the sales process. If you're not too familiar with positioning, this is definitely worth a watch!

6 - Marketing examples

Here's a gem: Marketing can be tough and confusing, especially if you're new to it and haven't seen much marketing done stuff before.

But don't worry! Harry Dry has made a collection of top-notch marketing examples that are on point and easy to understand ✨

Marketing Examples - 150+ short, sweet, practical examples

A gallery of real world marketing examples from successful companies. Want to perfect your cold email, boost referrals or improve SEO? Browse the case studies or filter by category. See something you like. And get inspired. It’s like Dribbble, but for marketers.

Marketing Examples

7 - Grow your product

There are countless ways to grow a product. Each product is unique and requires its own approach to growth. You can't simply copy and paste strategies that work for one product onto another.

Here, Andrea Bosoni has created a treasure trove of case studies! It's unbelievable that it's free! Binge-read it to uncover patterns in product growth.

Newsletter

8. Building as marketing

Passionate about building more than marketing? Check out this resource by Marc Louvion where he concisely outlines what free tool marketing is, why it's effective, and provides guidelines on how to execute it!

How to get customers with free tool marketing

How to market your micro SaaS using free tool marketing when you’re a solopreneur who loves coding.

Just Ship ItMarc Lou

There you have it, 8 invaluable resources to help you clear the fog of your Indie Hacker journey!

Before you go, I'm currently live on Product Hunt! 🚀

I've developed a visual finance tracker using Kanban boards.

It's my very first product launch, and any kind of support would mean a lot to me. 🙏😊

Support Budget Kanban on Product Hunt

Support Budget Kanban on Product Hunt!

Thank you for taking the time to read! If I miss anything, share it in the replies 😄 If you think someone else could benefit from this thread, feel free to share it!

Good luck with your Indie Hacker adventures!

PlanetScale and Ghost were previously incompatible due to differences in their support for foreign key constraints. With PlanetScale now supporting foreign key constraints, a seamless collaboration between the two is achievable. Nonetheless, there remain minor incompatibilities that require resolution.

The first part of this post will show you how to set up Ghost using Docker and PlanetScale. In the second part, we'll talk about the issues when putting PlanetScale and Ghost together and how to fix them. If you just want to get things going fast, you can skip the other parts.

Part 1 - Setting up Ghost and PlanetScale

Some warning

For PlanetScale to work with Ghost, make sure foreign key constraints are turned on. It's important to note that foreign key constraints are in beta on PlanetScale. If you decide to revert your database from beta, it could potentially disrupt your Ghost website. Additional information can be found here and here. This is a crucial point to weigh before changing providers.

A. Setting up database

1. Create a database in PlanetScale

Begin by creating a new database in PlanetScale. Follow the official quickstart guide available here. Assign a name to your database and make sure to jot down your connection details, such as the host, username, and password.

2. Activate "Foreign key constraints" in your database.

Ghost requires the use of foreign key constraints to function properly. Head to your database settings by selecting Database > Settings > Beta Features. Then, click on "enroll" next to "Foreign key constraints" to enable this crucial feature.

3. Great! Let's now move on to setting up Ghost itself.

B. Setting up Ghost

1. Install Ghost.

Installing Ghost can be done in various ways, and you can choose the one that suits you best by referring to its official installation guide. However, for the sake of reproducibility, this guide extends Ghost's official Docker image.

2. Customize your Ghost installation.

At this point, you have the option to add themes and adapters. However, delving into these aspects is beyond the scope of this article.

3. Patch the Ghost installation.

Ghost and PlanetScale have a minor incompatibility, which can be resolved by applying a patch. To do this, create a script named patch.sh with the following content:

ghost-docker-planetscale/bin/patch.sh at main · JustroX/ghost-docker-planetscale

Contribute to JustroX/ghost-docker-planetscale development by creating an account on GitHub.

GitHubJustroX

Finally, execute the patch by running:

chmod +x patch.sh
./patch.sh

Please be aware that, at the time of writing, this patch has only been tested with the latest Docker image (ghost:5.75.3) and its effectiveness may vary in future versions (or might become unnecessary). The specifics of the patch will be elaborated upon in the second part of this guide.

4. For Docker installation, here's the corresponding Dockerfile

FROM ghost:latest
COPY patch.sh patch.sh
RUN chmod +x patch.sh && ./patch.sh

Assuming everything goes smoothly, Ghost should now be configured to work seamlessly with PlanetScale. Now, let's proceed to connect them.

C. Connecting to the database

For configuring the database connection, use the PlanetScale connection details obtained from the previous steps and paste them into your Ghost configuration. Keep in mind that the value for database__connection__ssl should be set to [{"rejectUnauthorized":true}].

database__client=mysql
database__connection__database=<Your Planetscale Database Name>
database__connection__host=<Your Planetscale Database Host>
database__connection__password=<Your Planetscale Database Password>
database__connection__user=<Your Planetscale Database User>
database__connection__ssl=[{"rejectUnauthorized":true}]

The rest of the configuration process is akin to setting up a standard Ghost installation, which you can refer to in the official reference found here.

D. Run your Ghost instance

For Docker installation, launch your Docker container using the following command:

docker build . --tag ghost_example
docker run --env-file ./env ghost_example

Assuming a smooth process, you should observe your Ghost blog initializing and generating the necessary database tables. Once this initialization is complete, your Ghost blog integrated with PlanetScale should be live and ready!

E. Deployment (Optional)

I've created an example repository here for those looking to swiftly deploy a Ghost blog using PlanetScale. Simply follow the aforementioned steps for setting up the database and connecting to it. Beyond that, all that's required is to build and run the Dockerfile.

GitHub - JustroX/ghost-docker-planetscale

Contribute to JustroX/ghost-docker-planetscale development by creating an account on GitHub.

GitHubJustroX

I tested this using Railway, where all that's needed is to provide the repo fork and the necessary environment variables. Railway then automatically identifies the Dockerfile for building and running. The outcome is the blog website you're currently accessing.

F. Conclusion

That concludes the setup and deployment guide. Thank you for reading! If any parts are unclear or if you encounter issues with replication, feel free to reach out. I'd be happy to help. Just shoot me an email (thepiesaresquared@gmail.com) or DM/tweet me at @justfizzbuzz.

If you're intrigued by the challenges I encountered while integrating PlanetScale and Ghost, along with the eventual solution in the form of a patch, you can proceed to Part 2. 😄

Part 2 - Integrating Ghost 🤝 PlanetScale

In my view, there are three significant hurdles that both myself and fellow self-hosters faced when attempting to integrate Ghost and PlanetScale:

1. Configuring the value for database.connection.ssl
2. Ensuring foreign key constraints are supported by PlanetScale.
3. Addressing Ghost setup failures during initialization.

A. Configuring the value for database.connection.ssl

To overcome this initial challenge, it's crucial to establish a secure connection to the database since it resides outside the same network as the server. Attempting a direct connection without SSL/TLS results in the following error:

While seemingly minor, locating the value for database.connection.ssl can be challenging. Experienced developers might find it obvious, but for those who simply copy-paste from PlanetScale, it may not be as apparent. The community has resolved this configuration value since March last year, as discussed in this forum. From the discussion, the correct value for the configuration should be:

database__connection__ssl=[{"rejectUnauthorized":true}]

B. Foreign key constraints support for PlanetScale.

The second and primary challenge arose from the absence of foreign key constraints support in PlanetScale at that time. This presented a significant hurdle as Ghost heavily relies on this feature. In a Github discussion, PlanetScale's rep said that:

It looks there are at least a couple of big blockers here ... Seems like [Ghost] makes heavy use of foreign key constraints, a feature we don't support on PlanetScale

This is the point where most discussions on integration come to a halt and encounter a roadblock.

Fast forwarding to last month, PlanetScale made a significant announcement regarding the introduction of foreign key constraints support as a beta feature:

Announcing foreign key constraints support — PlanetScale

You can now use foreign key constraints in PlanetScale databases.

Taylor Barnett

With this recent development, achieving the integration is now technically feasible, a great time to resume and advance the integration efforts.

C. Addressing Ghost setup failures during initialization

i. The Problem

This particular challenge is a bit tricky. PlanetScale generates a database for you, and all you need to do is establish a connection. However, Ghost encounters startup issues because it erroneously assumes that the database still needs to be created. This manifests as either Ghost attempting to create the database despite its existence, or Ghost failing to detect that the PlanetScale database has already been established.

This concern was previously addressed in this discussion and ended with the following conclusion:

It doesn't appear that there's a ghost CLI option to run the initial setup without attempting to create the database, or any other built-in workaround for the problem you encountered.

To address this, my initial plan was centered around creating a Ghost fork and incorporating an option to skip the database creation step. Luckily, looking back, the solution turned out to be remarkably straightforward, with the bulk of my time dedicated to tracing the error and navigating through the code.

ii. Tracing Ghost's code

My initial strategy involves tracing the source of the error.

Given my limited familiarity with the majority of the codebase, I began following the execution flow of the source code, available at https://github.com/TryGhost/Ghost/blob/main/ghost/core. This journey starts from the initial Ghost initialization and progresses until I stumble upon a piece of code indicating the database creation. I tracked the code references, traversing through files such as index.js, ghost.js, boot.js, and DatabaseStateManager.js, until reaching what appeared to be a dead-end.

In DatabaseStateManager.js, Ghost triggers the initialization of the database by invoking the init method from a knexMigrator instance:

  await this.knexMigrator.init();

The knexMigrator is initialized using a class imported from another package named knex-migrator:

const KnexMigrator = require('knex-migrator');
...
this.knexMigrator = new KnexMigrator({
  knexMigratorFilePath
});
...

Given that it originates from another package, it seems like a dead-end because it likely adheres to a standard protocol for database initialization that might be fundamentally incompatible with how PlanetScale is configured. Additionally, tracing the code upward suggests there might be another package that needs forking to resolve this integration challenge between Ghost and PlanetScale.

Confronted with this challenge, I spent hours attempting to find a workaround to skip the database initialization within the ghost/core codebase. However, it turned out to be the REAL dead-end with the real breakthrough occurring when I decided to delve deeper into the "knex-migrator" package.

iii. Tracing knex-migrator package

Having exhausted other options, I decided to delve deeply into the "knex-migrator" package. The turning point in this ordeal occurred when I discovered that the "knex-migrator" package was owned by the TryGhost organization. You can view the repository here https://github.com/TryGhost/knex-migrator. This revelation indicated that the package was designed with Ghost in mind, and a potential solution might be just a simple pull request away from this repository.

Resuming the code tracing process, after investing some time, I successfully narrowed down the origin of the error when I identified the precise SQL command sent to PlanetScale. See line 126.

Notably, at line number 130, it became evident that the scenario where the database already exists had been accounted for. This discovery was somewhat surprising, considering the initial error reported by Ghost regarding the database already existing in PlanetScale. It implies that with PlanetScale, the SQL command triggers a different error number than the expected 1007 when attempting to create a database that already exists.

To confirm this, I inserted a console.error to log the error being caught at line 129, revealing:

Bingo! The error's errno is indeed different from 1007, which ultimately leads to the crash of the Ghost setup.

iv. Creating the patch

Based on the findings above, it appears that I don't necessarily need to create a Ghost setup option to skip database creation. Instead, I need Ghost to recognize that the error number originating from PlanetScale's database is not 1007.

To really resolve this issue, ensuring compatibility in error numbers is crucial. At this point, I don't have insight into where this difference in error numbers originates. It could be from the driver Ghost has utilized for communication with the MySQL database, or it might be specific to PlanetScale's implementation of the error. Individuals from the PlanetScale or Ghost's team reading this blog might have more ideas on this aspect than I do. 😀

But for my specific case, my primary goal is to achieve a functional deployment of Ghost. As a result, I am currently content with patching the currents/node_modules/knex-migrator/lib/database.js file with the following code:

  .catch(function (err) {
      // CASE: DB exists
      if (err.errno === 1007) {
          return Promise.resolve();
      }

      // Here's the patch
      const isPlanetScaleDBExists =
        err.errno == 1105 && 
        err.sqlMessage.endsWith("database exists");
        
      if (isPlanetScaleDBExists) {
          return Promise.resolve();
      }

      

      throw new errors.DatabaseError({
          message: err.message,
          err: err,
          code: 'DATABASE_CREATION_FAILED'
      });
}

To facilitate this, I crafted a script that patches Ghost during Docker build time.

file_path="current/node_modules/knex-migrator/lib/database.js"
text_to_add="const isDBExists = err.errno == 1105 && err.sqlMessage.endsWith('database exists');\\
if(isDBExists) return Promise.resolve();\\
"
line_number=129

sed -i "${line_number}i${text_to_add}" "$file_path"

The script above is designed to inject JavaScript code into the source code of the knex-migrator.

v. Final result

After crafting the patch, it took an additional hour or two to ensure my environment variables were correctly configured. Once everything fell into place, I was thrilled to finally deploy my Ghost website!

With the successful import of my blogs from the previous deployment, this Ghost site was up and running smoothly, with the database now hosted on PlanetScale! 🙌

Final Thoughts

Thank you for reading!

I appreciate you taking the time to read up to this point ❤️. If you find any parts confusing or have any issues with replication, I'd be happy to help. Just shoot me an email (thepiesaresquared@gmail.com) or DM/tweet me at @justfizzbuzz.

I thoroughly enjoyed the process of making PlanetScale and Ghost work seamlessly together! If you're interested in more posts like this, I invite you to subscribe to this blog, or let's connect and share our posts on Twitter!

Thank you 👨‍💻

In this blog post, we will introduce you to four amazing design generators that will help you create stunning designs effortlessly. These generators are user-friendly and offer a wide range of options to suit your needs. Let's dive in!

Neumorphism.io: Neumorphism is a design trend that combines skeuomorphism and flat design elements to create a soft and realistic visual effect. The Neumorphism.io generator allows you to experiment with this style by providing sliders for various parameters such as light source direction, intensity, and contrast. With just a few clicks, you can achieve a visually pleasing neumorphic design that will make your project stand out.

UI Glass Generator: If you're looking for a sleek and modern glasmorphism effect for your interface elements, look no further than the UI Glass Generator. This generator offers an array of customization options, including color selection, transparency control, and blur intensity. Whether it's buttons, cards, or navigation bars, this tool has got you covered.

Smooth Shadows: Shadows can add depth and dimension to any design element when used correctly. The Smooth Shadows generator helps you create beautifully crafted shadow effects effortlessly. With adjustable parameters like blur radius, spread distance, and light source angle, you can achieve the perfect shadow effect for your project in no time.

Haikei.app: Backgrounds play a crucial role in setting the mood and enhancing the overall aesthetic appeal of your designs. Haikei.app is an incredible generator that allows you to create unique and eye-catching backgrounds with ease. Choose from various shapes, patterns, and color palettes to create a background that complements your design perfectly.

These design generators are incredibly helpful for designers of all skill levels. Whether you're a beginner looking to experiment with different styles or an experienced designer looking to save time, these tools have got you covered. So, give them a try and see how they can elevate your design projects to the next level!

In this article, I'll explain why flipping your Kanban board can effectively reduce project anxiety and offer a clearer perspective on your tasks.

Uncertainty = Anxiety

Let's start by recognizing that a significant source of stress and anxiety in our lives is uncertainty. When we're uncertain about the future, it can lead to a sense of unease and overwhelm. To address this, we naturally tend to view the moments closer to the present as more certain than those further into the future. If we were to graph this uncertainty over time, it might look something like this:

As time progresses, uncertainty narrows down, and we gain a better understanding of what lies ahead. This reduction in uncertainty allows us to tackle tasks with greater confidence, enabling us to focus on one thing at a time.

The Problem with Conventional Kanban Boards Layout

However, when it comes to traditional Kanban boards, there's a mismatch between our natural perception of time and the way tasks are typically organized. Most Kanban boards are set up from left to right, representing the progression of tasks. Unfortunately, this orientation often presents uncertainty in a counterintuitive manner:

Completely opposite! As you can see, the conventional Kanban board places uncertainty closer to the "origin" of the board. At a glance, you're confronted with an overwhelming list of tasks in the backlog, which can fuel anxiety.

What if we flip it?

Consider flipping your Kanban board to create a more intuitive representation of uncertainty:

In this flipped version, your accomplished tasks take center stage. This layout is much more intuitive and natural to think about. Instead of being immediately confronted by an ever-growing backlog, you're greeted by the tasks you've successfully completed. This shift in focus can be incredibly motivating and encouraging, rather than inducing guilt or anxiety about unfinished tasks.

My Implementation

To provide a practical example of how you can implement a flipped Kanban board, I'd like to share my own setup, which has proven itself to reduce my anxiety and enhance my productivity.

1. Done: This is where I place tasks that I have successfully completed. Celebrating achievements is an essential part of this method and helps boost motivation.
2. Doing: The "Doing" list is where I place tasks that I'm actively working on. These are the items that are currently taking up my focus and attention.
3. Waiting For: In this list, I track tasks that are dependent on external factors or waiting for input from others. It helps me keep tabs on pending tasks without cluttering my main workspace.
4. Week: This list is dedicated to tasks I plan to complete within the current week. It helps me set weekly goals and prioritize tasks effectively.
5. List of Active Projects Requiring Weekly Review: Here, I maintain a list of ongoing projects that require regular review. By having this dedicated space, I ensure that important projects are consistently monitored.

Benefits of This Layout:

1. Enhanced Intuitiveness: The layout is designed to be intuitive and aligns with our natural perception of time. It's easier to visualize progress and prioritize tasks effectively.
2. Motivation: Placing completed tasks at the forefront is motivating. It encourages a positive mindset and reinforces a sense of accomplishment.
3. Reduced Anxiety: The reduced focus on an overwhelming backlog minimizes anxiety and helps maintain a calm workflow.
4. Diagnosing Bottlenecks: One of the advantages of this layout is that it makes it easier to diagnose issues in your workflow. If you notice that cards are not following a smooth diagonal flow from "Week" to "Done," it's a sign that there might be a bottleneck somewhere in your process. This visual cue allows for quick identification and targeted improvement.

Conclusion

Flipping your Kanban board offers a simple trick to reduce anxiety by aligning the representation of uncertainty with our natural perception of time. This layout is not only more intuitive but also helps you approach your tasks with greater ease, ultimately leading to a more productive and less stressful workflow. Give it a try and let me know what you think!

Conflict-free replicated data types (CRDT) is one data structure I found truly fascinating. Basically, it enables distributed machines to eventually sync their data over time, i.e., eventual consistency.

To illustrate what I mean, consider the following scenario:

• Two person, A and B, are doing collaborative work in a shared document, e.g., Google Docs
• There is no centralized server managing the state b/w A and B.
• A sends state updates to B, then B changes it's state to reflect A's updates, and vice versa.    

Now, for some unknown reason, they got disconnected from each other for some time intervals. During this time, both person made changes to the document. Once they are reconnected, how should the program resolve their updates such that both have equivalent states?

One simple approach is to append timestamps to the updates and order events based on the timestamps. This approach, however, is predicated on the assumption that both machines have synchronous clocks that are immune to drifting and modification. This may result in data corruption depending on your use case.

CRDTs are intended to address this issue. Essentially, the goal is to structure the state updates in such a way that merge conflicts cannot occur*. This is accomplished by creating a data structure that has the following properties:

• Merging updates are commutative - which means that if we have a MERGE function that applies state updates, the order in which each update is applied should be irrelevant to the resulting state.  

   C = MERGE( A, B) = MERGE(B, A)

• Merging updates are idempotent - which means that merging the same updates more than once results in the same state.  

   C = MERGE( A, B ) = MERGE(C , A) = MERGE(C, B)    

This is essentially combining updates in any order and frequency while producing the same result. This makes it ideal for distributed systems where communication packets may arrive duplicated, late, or in an erroneous order.

This approach is quite powerful and is widely used in distributed systems today. It's the ability to resolve conflicts in distributed databases as well as synchronize multiple nodes of a distributed system makes it an essential tool in today's systems.

Playing with CRDTs

There are a lot of implementations of CRDTs out there. In JavaScript, for instance, we have Y.js (https://github.com/yjs/yjs) and automerge (https://github.com/automerge/automerge). There’s also a Y.js demo (https://demos.yjs.dev/prosemirror/prosemirror.html) that allows you to play around with them and have your collaborative app running in just a few seconds. All messages are exchanged via webRTC while the state is managed via CRDTs. This can be a great sandbox to understand how CRDTs work.

I also attempted to build an offline-first application with Y.js-powered device syncing. The goal is to create a habit-tracking app that does not rely on a central server (https://habit-board.netlify.app).

Four days since the start of the year. So far so good pic.twitter.com/h8K9Df5QUD

— 🚲 Just (jxtro) (@justfizzbuzz) January 4, 2022

I had a lot of fun messing around with it. Overall, CRDTs are an incredibly useful structure for distributed systems and are gaining a lot of momentum. It's definitely worth investing time in them to better understand how they work and how you can apply them.

Conclusion

In conclusion, CRDTs provide an efficient way to keep distributed systems in sync. By structuring their data in such a way that merging is commutative and idempotent, they are able to maintain the same consistency regardless of delivery order and duplicate packets. This technique is widely used in distributed systems today and is gaining more and more traction. It’s definitely worth looking into this structure and understanding how it works and how you can apply it in your own systems.

* I may be relaxing some jargon here, what I mean is that there’s a deterministic algorithm or scheme that is guaranteed to combine any state updates such that no merge conflict, that demands manual resolution, is produced.

References

• https://www.youtube.com/watch?v=M8-WFTjZoA0&t=1821s&ab_channel=TL%3BDR%2F%2FJavaScriptcodecastsforworkingdevs
• https://www.youtube.com/watch?v=iEFcmfmdh2w&t=835s&ab_channel=CodingTech

In my own opinion, educational content about social media consumption management is more effective in the long run than clichéd calls for total social media cut-off.

I mean, social media detox is beneficial, but it wouldn't hurt if we could also encourage people to find positive communities so they wouldn't get drained as much. It's much more productive than vilifying social media usage.

Banning social media usage appears to be a band-aid solution. Everyone will get back to social media eventually, one way or another. It's a technology that I believe is unavoidable. It's similar to how people demonize televisions, computers, and cell phones. Those who avoided it for various boomer reasons are now left out because they have fewer opportunities to explore and learn how to manage it. The same pessimistic trends are emerging, but this time for social media usage. I'm sure those who avoid social media will miss out on the opportunities it provides.

Discovering our sense of belonging, on the other hand, addresses the root cause. Remember that social media is about people. So find your people. Follow your genuine interests.  Search for an engaging community. Engage in positivity. Also, don't inform your real-life friends because you know how toxic they could get. Be ruthless in blocking and muting people with so much hate and resentment. Surround yourself with inspiring and motivating people. I hope it'll change how you view social media. Good luck!

Here are my opinions on the question of whether artificial intelligence (AI) and robots should be granted rights comparable to those of humans.

It's been a long philosophical and scientific quest to define the differentiating factor that comprises a conscious being. Biologists may be keen on using the taxonomical approach, but this relies on the fact that the determining factor lies within the physical structure of the being (e.g. its DNA), and may completely disregard that it may be an emergent property that other physical structures might also exhibit. Theology-inclined individuals may lean on the existence of a soul, but properties exhibited by a soul-bounded being are not well-defined and is a heartbreaking risk if replicated. Speaking of which, from a thought experiment that most computer scientists are familiar with, if an entity exhibits a behavior indistinguishable from the behaviors observed on soul-bounded beings, then, the existence of a soul doesn't really matter. This is a modified and rephrased Turing Test applied to the presumed existence of a soul.

One of the most pushed forward factors contributing to consciousness is rationality. Although this may come intuitive, if we stop there we are left with an incomplete picture. Rationality alone can not define a conscious being. We already have supercomputers, control systems, and processes that crunch huge amounts of data and apply them to their use-cases rationally. Not to mention, human beings, assumed to be a prime example of conscious beings, do not always act rationally. Thus, rationality is not the end-all and be-all of consciousness.

If we look closely, rationality is not even the one making the shots. Being rational in a risk-free, noise-free, perfect environment is a waste of time and energy. Why do you need to be smart if the world is perfect? Why possess a problem-solving brain if there is no problem to solve? In a perfect world, we are all dumb. We only get smart because we live in a world of limited time and energy and we have an irrational craving to optimize our existence. That optimization requires rationality.

In light of this, it's possible that irrationality contributes to consciousness as well. Our rationality lacks direction on its own because there isn't an inherent variable to optimize into, i.e., there isn't an inherent reason to live and there isn't an inherent need to exist. However, our irrationality somehow determines the course of existence and aspires to add color to this depressingly objective reality. Rationality optimizes whatever irrationality wants.  Hence, irrationality is the king, while rationality is the slave.

As a byproduct of evolution, our rationality optimizes our irrational desires to live, survive, and matter. We are just aimless intelligent beings without an irrational desire that directs our course. Our creativity is fueled by our irrationality. Our inner drive tells us this.

That said, perhaps our capacity to justify our irrationality is what distinguishes us from other species. We strike at the very core of autonomy and freedom when we use our rationality to justify our irrationality. We can make up stories, aspirations, and narratives to support our irrational need for food, affection, and survival. Perhaps that is ultimately what makes us human.

Consciousness, autonomy, and sentience, are the pillars of our moral circle, and by extension, its codification into our guidelines, laws, and constitutions.  But it's not one of nature's physical laws that only humans may possess these properties. So I think it's not fair that these codifications only apply to human beings.

The fundamental tenet of the Universal Declaration of Human Rights is that everyone has unalienable rights that respect their individual freedom and autonomy. I believe that once we develop or come across beings that can rationally justify their irrationality, i.e., can defend their autonomy, freedom, and liberties, then our laws and constitutions should also take them into account.

Does this imply that I believe robots ought to have rights? It varies. They should be able to justify their irrationality, for starters. Robots that are pre-programmed and unable to generalize problems are automatically excluded by these criteria. It appears to be simple, and big-tech companies could make this right now with decent accuracy. Finding the root of their irrationality is more difficult, though.

If their irrationality comes from a human being controlling them, then they're not autonomous - they are merely tools and not conscious beings. These criteria then rule out AIs that behave like sophisticated data encoders and decoders; BTW, the majority of AIs presently in use are simply sophisticated encoders and decoders, e.g., Give me a sentence -> I'll do some math -> Outputs another sentence. On the other hand, if the robot's irrationality stems from within, meaning that they are free to choose and think for themselves, then they are autonomous and should have the same civil liberties as humans.

Idk. Just a thought.

The Happiness Equation by Neil Pasricha is the most therapeutic book I've read. The book's central thesis is straightforward:

Want Nothing + Do anything = Have Everything

But I believe the most paradigm-shifting insight came from the first chapter. We are accustomed to believing that in order to be happy, we must work hard and achieve great success, i.e., happiness is a by-product of hard work and success. However, according to the book, this is backward: happiness is the precursor, not the byproduct, of doing great work that will eventually lead to success.

Although it may appear to be counterintuitive at first, the "Be happy first" mindset is reasonable. You are more engaged and focused when you are happy. And when you're engaged and focused, you produce excellent results! In addition, the book suggests research-backed activities that can make people happy in order to start a happiness-work-success flywheel:

1. Three walks
2. The 20-minute replay
3. Random acts of kindness
4. A complete unplug
5. Hit Flow
6. 2-minute meditations
7. Five gratitudes  

This simple shift in mindset has far-reaching consequences. For one thing, I've noticed that this mindset makes me less frustrated with my output and less likely to overthink whether any activity will be fruitful. I believe the most significant effect was the shift from seeking personal validation for my performance to simply accepting the inherent joy I felt while doing the work.

This book has so many insights, and I'm glad I read it before starting college, where most of us were emotionally challenged and tested. It's also one of my go-to books when I'm feeling down. Most insecurities and unhelpful anxieties are eliminated by adopting this mindset. To be honest, it just makes my daily activities more enjoyable.