Frank Hampus Weslien

Going Full Agentic

2026-02-14T00:00:00+00:00

When I joined Upptec in October 2024, I got a Cursor license. Previously, I had only used Copilot — useful, but not revolutionary.</p>

Over 2025, I gradually learned where AI shines and where it falls apart. I leaned heavily on tab completion, then started using the chat interface more and more, though I was still hand-picking which files to reference. A real shift came when the agents gained a planning mode. That extra reasoning step improved quality enough that I could throw harder problems at them, as long as they weren’t too complex.</p>

But the past week changed everything. My team started fully leaning into agentic workflows, and the true unlock turned out to be skills and MCP servers — giving the AI structured context so it produces the right diff. I was blown away by the quality improvement, even using the same model.</p>

I’m going full agentic.</p>

Why Elixir works for agents</h4>
We write Elixir at Upptec, and it turns out Elixir is surprisingly well suited for agentic workflows. This might sound like cope from an Elixir dev, but hear me out.</p>
Functional code has a property that matters a lot for AI agents: local reasoning. When a function takes inputs and returns outputs without mutating state elsewhere, an agent can reason about that function in isolation. It doesn’t need to hold the entire application in its head. Cause and effect are right there, next to each other.</p>
Functional code is also easier to test. This matters because agents love loops — write code, run tests, fix failures, repeat. The tighter that feedback loop, the better the output. Pure functions with clear inputs and outputs make for dead simple test cases.</p>
Dashbit (the company of José Valim, creator of Elixir) wrote a great post about why Elixir works well with AI</a>. Worth a read.</p>
Then there’s Tidewave</a>, an MCP server for Elixir that’s genuinely brilliant. It lets your AI agent tap into runtime information from the running application — query the database, read logs, execute code, find documentation. Having that kind of introspection available to an agent is a game changer.</p>

Where it fell apart</h4>
But Elixir being agent-friendly doesn’t mean all Elixir code is agent-friendly.</p>
We have some older projects where the agents produced genuinely nasty code. The worst offender: LiveView components. The agents kept misunderstanding that LiveView components don’t have their own process. They’d send messages everywhere, creating spaghetti that no human would ever write. In clean codebases, the agents sang. In messy ones they made the mess worse.</p>
The fix came from my colleague who added a bunch of skills and MCP servers to our setup — giving the agents better context about how our codebase actually works. The quality improvement was immediate and obvious. Agents are only as good as the context you give them.</p>
Optimizing the workflow</h4>
So the agents work. Now the question is: how do I get more out of them?</p>
We have a custom MCP server at work built with the Anubis framework</a>, but it’s buggy. The framework itself needs work. That’s near the top of my list — a reliable MCP server makes everything else better.</p>
Then there are all my other development tools. Right now I use VS Code. It’s comfortable — nice diff view, file tree on the left, Claude in a vertical split, terminal at the bottom. Everything visible at once. But if I want to run multiple agents simultaneously, a GUI editor starts feeling like a bottleneck. I might need to take another look at workflows that stay 100% within the terminal. Using a combination of Neovim and tmux, it might be possible to create a much more integrated experience.</p>
Another question is how multiple agents work on the same project at the same time. Some people use git worktrees. Others just clone the repo into multiple folders. I haven’t settled on an answer yet.</p>
But that’s what 2026 is about: going from managing one agent to managing many. I’m ready to build.</p>
/Cheers</p>

Cloud in a box

2025-03-21T00:00:00+00:00

I’ve been writing Elixir professionally for a while now, and something’s been bugging me: we’re not using its coolest feature. The BEAM VM (Erlang’s virtual machine) lets you distribute your application across multiple nodes seamlessly, yet most of us still deploy microservices. Why?</p>

Let’s look at the common reasons for choosing microservices:</p>

“Different services need different languages”</p>
- Python for ML</li>
- Rust for performance</li>
- Node.js because that’s what the team knows</li> </ul> </li>
- “We need isolation”</p>
  - If one service crashes, others keep running</li>
  - Different teams own different services</li>
  - Separate deployment pipelines</li> </ul> </li>
  - “We want clean dependencies”</p>
    - New services start fresh</li>
    - No legacy code</li>
    - Modern libraries</li> </ul> </li> </ol>
      But here’s the thing: these are all solvable problems in a monolith.</p>
      Need different languages? Write FFI bindings. Yes, it’s work, but it’s one-time work versus the constant overhead of service boundaries. The BEAM VM already has excellent FFI support for Rust and C.</p>
      Worried about isolation? The BEAM VM solved this decades ago. Its actor model and “let it crash” philosophy give you better isolation than network boundaries. Each process is isolated, supervised, and can crash without taking down the system.</p>
      Want clean dependencies? That’s what modules and proper architecture are for. If you’re making microservices to avoid refactoring, you’re just pushing the complexity into your network calls.</p>
      Team ownership? Use proper modules and interfaces. Conway’s Law doesn’t mandate network boundaries.</p>
      The real reason we choose microservices is that they’re easier right now. It’s faster to start a new service than to fix the old one. It’s easier to use a different language than to write FFI bindings. It’s simpler to deploy separately than to figure out proper module boundaries.</p>
      But this is death by a thousand cuts. Each service adds:</p>
      - Distributed logging</li>
      - Service discovery</li>
      - Network failure handling</li>
      - Deployment pipelines</li>
      - Monitoring</li>
      - Message serialization</li>
      - API versioning</li> </ul>
        What’s the alternative? Languages like Elixir (and experimental ones like Unison) show us a better way: write as a monolith, deploy as distributed. Imagine telling your runtime: “This module needs more CPU” or “This code should run close to the database.” No microservices, just deployment annotations.</p>
        We need deeper integration between languages and cloud platforms. Our code should be able to dynamically request resources, spawn processes across nodes, and handle distribution - all while looking like local function calls.</p>
        The future isn’t more microservices. It’s better abstractions for distribution, built into our languages and runtimes. We just need to stop taking the easy way out and start building those abstractions.</p>
        /Cheers</p>

My Programming Commandments

2025-03-09T00:00:00+00:00

These are my programming commandments. They’re not a treasure map that guarantees success, but they’re a solid compass that keeps me heading in the right direction. Over time, I’ve found that sticking to these makes my code easier to maintain, reason about, and extend. So here they are:</p>

1. Prefer local state to global state</h3>
Global state is that one friend who always crashes on your couch and messes up your stuff. Keep it local whenever possible. Your future self (and your teammates) will thank you.</p>

2. Prefer immutable to mutable</h3>
Mutability leads to spooky action at a distance. If something shouldn’t change, don’t let it. Immutable data is predictable, safe, and easier to debug.</p>

3. Prefer composition over inheritance</h3>
Inheritance can be a trap. Before you create another subclass, ask yourself: could this be done with composition instead? Most of the time, the answer is yes.</p>

4. Prefer purity to impurity</h3>
Pure functions are little islands of sanity in an ocean of side effects. They take input, return output, and don’t mess with the world in between.</p>

5. Parse, don’t just validate</h3>
Validating says, “This input is wrong.” Parsing says, “Let’s turn this into something useful.” The latter is way more helpful.</p>

6. Try to make as much as possible run locally</h3>
Relying on remote services slows you down. If you can develop, test, or prototype locally, do it.</p>

7. Automate the repetitive stuff</h3>
If you’ve done it twice, script it. If you’ve done it three times, make it a proper tool. Your time is too valuable for manual drudgery.</p>

8. Test early, test often</h3>
Tests are like seatbelts: annoying until you need them. Write them before you regret not having them.</p>

9. Write code for humans</h3>
Code is read way more often than it’s written. Make it clear, make it simple, and make it make sense.</p>

10. YAGNI (You Ain’t Gonna Need It)</h3>
That feature you’re “pretty sure” you’ll need later? You probably won’t. Solve today’s problems today.</p>

11. Premature optimization is the root of all evil</h3>
Fast code is good, but maintainable code is better. Optimize when it actually matters.</p>

12. Are they similar or are they the same?</h3>
Not all duplication is bad. Only share code when changing one part means you must change the other.</p>

13. The Rule of Three</h3>
If you see a pattern once, ignore it. Twice? Keep an eye on it. Three times? Now it’s time to refactor.</p>

14. Refactor as you go</h3>
Bad code gets written. The trick is to not leave it bad. Refactoring a little at a time prevents big rewrites later.</p>

15. Never fail silently</h3>
Silent failures are the worst. If something breaks, scream about it—log it, throw an error, do something! Debugging ghosts is not fun.</p>

Ode to Plain Text

2025-03-02T00:00:00+00:00

Oh, simple script upon the page,
Nothing is easier to engage.
No bloated app, no fickle style,
Just truth inscribed in lines worthwhile.</p>

Markdown dances, clean and bright,
Her syntax shaped by God’s light.
Headers bold, italics lean,
Asterisks where stars convene.</p>

Inside Obsidian’s boundless vault,
You do your job without fault.
No tangled chains of locked-in lore,
Just knowledge free forevermore.</p>

And when we make a silly mistake,
Git is there to pull the brake.
Undo, revert, reset, amend,
A safety net that will not bend.</p>

And Grep, the seeker, keen and true,
Cuts through the jungle, to clear the view.
A searching blade through tangled vines,
He spits his truth line by line.</p>

Oh, plaintext with your timeless grace,
You expand our thoughts into space.
No walls, no chains, no hidden keys,
Just letters dancing, wild and free.</p>

The Art of Code: Sculpting vs Operating

2025-02-23T00:00:00+00:00

When you’re new to a codebase, writing code feels like performing surgery. You move cautiously, trying to cause minimal damage to the surrounding tissue. You develop diagnostic techniques to observe the system’s state and measure its health. Every change is preceded by careful examination and followed by thorough testing.</p>

But as you master the codebase, coding transforms into sculpting. You see the code’s potential shape within the existing structure. You move pieces around freely, confident in your understanding of how they fit together. If something breaks, you quickly mend it. The fear is gone, replaced by creative freedom.</p>

The transition from surgeon to sculptor marks a true shift in productivity. It’s when you stop asking “What might I break?” and start asking “What could this become?”</p>

The Secret to Waking Up Well Rested

2025-02-16T00:00:00+00:00

I won’t drag this out: the secret is to not have an alarm.</p>

Of course, not everyone has the luxury of sleeping without an alarm, but if you’re like me and don’t have to be at work before 9 AM, give it a try. Sometimes I set an alarm for early meetings or travel, but otherwise, I just make sure to go to sleep around 10-11 PM, winding down with a book and voilà! I wake up at 7am feeling refreshed.</p>

If you do this, you’ll discover two major benefits: you always wake up rested (doh! it’s in the title) and you’ll likely sleep more efficiently. Sometimes I only need 5-6 hours and wake up at 5 AM. I usually stay in bed for a while until I get motivated to start my day - whether that’s watching a movie, working on a programming project, or writing a blog post.</p>

So please do yourself a favor and try turning off your alarm.</p>

A new Olympics

2024-11-30T00:00:00+00:00

The Paris Summer Olympics recently wrapped up, showcasing an overwhelming array of over 40 sports. While the event brought thrilling moments, the sheer number of disciplines leads to a diluted experience. I want to propose a new Olympics with fewer sports.</p>

Here’s a glimpse of the current lineup:</p>

Aquatics (Swimming, Marathon Swimming, Diving, Water Polo, Artistic Swimming), Archery, Athletics, Badminton, Basketball (3x3, Basketball), Boxing, Breaking*, Canoe (Canoe Sprint, Canoe Slalom), Cycling (BMX Freestyle, BMX Racing, Road Cycling, Track Cycling), Equestrian (Equestrian Eventing, Equestrian Dressage, Equestrian Jumping), Fencing, Football, Golf, Gymnastics (Artistic Gymnastics, Rhythmic Gymnastics, Trampoline Gymnastics), Handball, Hockey, Judo, Modern Pentathlon, Rowing, Rugby (Rugby Sevens), Sailing, Shooting, Skateboarding*, Sport Climbing*, Surfing*, Table Tennis, Taekwondo, Tennis, Triathlon, Volleyball (Beach Volleyball, Volleyball), Weightlifting, and Wrestling (Greco-Roman Wrestling, Freestyle Wrestling).</p>

Simplifying the lineup could enhance the viewing experience by focusing on sports that truly embody the Olympic spirit.</p>

Key principles for a refined Olympic experience:</p>

Athletes should not win gold in multiple sports.</li>

Exclude team sports.</li>

Emphasize pure athleticism: who can throw the furthest, jump the highest, or run the fastest.</li>

Avoid subjective judging.</li> </ul>
With these criteria in mind, the sports that remain are:</p>

Swimming</li>
Athletics</li>
Weightlifting</li> </ul>
These sports all have multiple events which will need some further pruning</p>
Athletics</a></h3>
Atheletics consists of several events:</p>
Men & Women:</p>
</th> </th> </th> </th></tr></thead>

100m</td> 200m</td> 400m</td> 800m</td></tr>
1500m</td> 5000m</td> 10,000m</td> Marathon</td></tr>
3000m Steeplechase</td> 110m Hurdles</td> 400m Hurdles</td> High Jump</td></tr>
Pole Vault</td> Long Jump</td> Triple Jump</td> Shot Put</td></tr>
Discus Throw</td> Hammer Throw</td> Javelin Throw</td> 20km Race Walk</td></tr>
4 x 100m Relay</td> 4 x 400m Relay</td> </td> </td></tr> </tbody></table>
Unique events:</p>

Men’s Decathlon</li>
Women’s Heptathlon</li>
Marathon Race Walk Relay Mixed</li> </ul>
Here is my suggestion:</p>
</th> </th> </th> </th></tr></thead>

100m</td> 1500m</td> 5000m</td> 10,000m</td></tr>
High Jump</td> Pole Vault</td> Long Jump</td> Shot Put</td></tr> </tbody></table>
I removed the following events for clarity and focus:</p>

200m and 400m</strong>: These distances are too similar to the 100m.</li>
800m</strong>: Too similar to the 1500m.</li>
Hurdles</strong>: Not in the olympic spirit. It is about running as fast as possible, not jumping over obstacles</li>
3000m steeplechase</strong>: Similar reasoning as for hurdles.</li>
4 x 100m relay</strong>: Excluded as it is a team event.</li>
Triple jump</strong>: Only one jump event is necessary.</li>
Throwing events</strong>: Retained only the shot put for simplicity.</li>
Women’s Heptathlon</strong>: I do not like multi-sport events.</li>
Walking events</strong>: You shuold run as fast as possible and not put artifical constraints like “you can only walk”.</li>
Decathlon</strong>: I do not like multi-sport events.</li> </ul>
Swimming</a></h3>
Swimming also consists of to many events:</p>
Event Type</th> Distance/Style</th></tr></thead>

Freestyle</td> 50m, 100m, 200m, 400m, 800m, 1500m</td></tr>
Backstroke</td> 100m, 200m</td></tr>
Breaststroke</td> 100m, 200m</td></tr>
Butterfly</td> 100m, 200m</td></tr>
Individual Medley</td> 200m, 400m</td></tr>
Freestyle Relay</td> 4 x 100m, 4 x 200m</td></tr>
Medley Relay</td> 4 x 100m</td></tr>
Mixed Medley Relay</td> 4 x 100m</td></tr> </tbody></table>
These are my suggestions:</p>

100m Freestyle</li>
1500m Freestyle</li> </ul>
It is unnecessary to have separate events for different swimming styles over the same distance; the essence of the sport is to swim as fast as possible. Additionally, swimmers win to many medals. It ain’t right that the events are so similar that the same athlete can win gold in multiple events. Michael Phelps has 28 olympic medals, 23 golds. Ridiculous.</p>
Weightlifting</a></h3>
Weightlifting currently features five weight classes for both women and men:</p>
Women</th> Men</th></tr></thead>

49kg</td> 61kg</td></tr>
59kg</td> 73kg</td></tr>
71kg</td> 89kg</td></tr>
81kg</td> 102kg</td></tr>
+81kg</td> +102kg</td></tr> </tbody></table>
But why have weight classes at all? Shouldn’t the ultimate goal be to lift the heaviest weight possible? In my new version of the Olympics, weight classes would be eliminated.</p>
Conclusion</h2>
My new version of the Olympics offers a more focused and compelling narrative. It concentrates on the core elements of human athleticism—speed, strength, and endurance—and celebrates the essence of competition. The olympics then becomes a story of human potential at its peak.</p>

What comes after nationalism?

2024-11-24T00:00:00+00:00

The nation state as we know it today emerged during the 1800s. Before that, especially in Europe, people didn’t really think of themselves as part of “nations” - they belonged to their local village, their church, or maybe pledged loyalty to a distant monarch. But then came the age of new technologies: mass-printed newspapers, railways connecting distant cities, and later radio and the telegraph. These tools made it possible to imagine a bigger “we” - the nation state was born.</p>
This transformation wasn’t just technological - it was driven by leaders who saw the potential. Giuseppe Mazzini preached Italian unity, while Bismarck forged Germany through “blood and iron.” In France, the revolution had already planted the seeds of national identity, which Napoleon III would later cultivate. These leaders used new communication tools to spread national myths, standardize languages, and create the shared stories that made people feel part of something bigger than their local community.</p>
Ever since John Perry Barlow’s “Declaration of Independence of Cyberspace”</a> in 1996, we’ve seen hints of what might come next. The 21st century brings its own revolutionary technologies: the borderless internet, blockchain, peer-to-peer networks, and global social media. But perhaps the most powerful “technology” of all is the emergence of English as a global lingua franca - for the first time in history, humans across the planet can easily communicate in a shared language. Combine this with instant translation tools, and we’re rapidly breaking down the last remaining barriers to global understanding.</p>
We’re already seeing glimpses of this post-national identity: digital nomads who feel more connected to their online communities than their physical locations, global movements like climate activism that transcend borders, and international collaborations in science and art that ignore national boundaries. The rise of remote work means your closest colleagues might live on different continents.</p>
These aren’t just tools or trends - they’re the building blocks of something bigger. They’re letting us construct an even larger “we” - perhaps the final “we”: humanity itself. This isn’t just idealistic thinking - it’s a practical response to challenges that don’t respect national borders: climate change, pandemics, artificial intelligence, and space exploration all require global cooperation and a species-level perspective.</p>
We’re living through this transformation right now, which makes it hard to see the full picture. Just like a French peasant in 1800 couldn’t imagine identifying with someone hundreds of miles away in Paris, we might struggle to grasp how technology is rewiring our sense of belonging on a global scale.</p>
Sure, there are still many questions to answer about what a post-national world might look like. But perhaps the most compelling argument for moving beyond nationalism is this: throughout history, nothing has been more destructive than wars between nation states - conflicts built on artificial divisions between people who share the same hopes, fears, and dreams. As these old boundaries blur and dissolve in the digital age, maybe we’ll finally see that the deadliest conflicts in human history were fought over lines drawn on maps that never mattered in the first place.</p>

Public Money, Public Code

2024-11-11T00:00:00+00:00

When your tax money funds software development, shouldn’t you get to see and use what you paid for? It’s a simple idea: if the public pays for it, the public should own it.</p>
Sweden has roughly 300 municipalities, 20 regions, and one state government. Each builds or buys their own software, often solving the same problems hundreds of times over. Imagine if instead:</p>

Every municipality shared a common, open-source website template</li>
Healthcare systems actually talked to each other</li>
Public transit apps worked across regional borders</li>
Building permits were handled through the same streamlined system</li> </ul>
We’re not dreaming big enough. Look at Britain’s GOV.UK - a unified design system and platform that makes government services accessible and consistent. Or Estonia’s X-Road, which connects their entire digital government infrastructure.</p>
The Vision</h2>
Picture a GitHub organization called “SwedenPublic”. Inside, you’d find:</p>

A municipal website template that any kommun can fork and customize</li>
A standardized API for public transit data</li>
Shared components for everything from e-services to permit applications</li>
Security-audited libraries for common government needs</li> </ul>
When Malmö develops a better way to handle building permits, Umeå can benefit immediately. When Stockholm creates an improved snow plow tracking system, Göteborg can deploy it before next winter.</p>
Beyond Borders</h2>
Why stop at Sweden? The challenges of local government aren’t unique to us. A Norwegian kommun faces the same basic needs as a Swedish one. The same goes for Denmark, Finland, or Germany.</p>
This isn’t just about saving money - though we’d save billions. It’s about building better tools, faster. It’s about transparency. It’s about working together instead of reinventing wheels in 300 different municipalities.</p>
The code is already paid for. Let’s make it work for everyone.</p>

Why you should long to do, not just to have done.

2024-08-24T00:00:00+00:00

When I was young, I played the guitar—or at least, I tried to. I dreamed of being a rock star, but I didn’t want to practice. Without putting in the necessary time and effort, I was a terrible student who made little progress. I was too focused on the end goal rather than enjoying the journey.</p>
Fast forward to my twenties, and I decided to learn how to paint. This time, I approached things differently. I dedicated a significant amount of time to practice, but more importantly, I shifted my focus from the end result to the process itself. By concentrating on the act of painting rather than worrying about becoming a great painter, I improved rapidly. With each brushstroke, I learned something new, and my skills grew. It didn’t take long before I exceeded my own expectations. It felt amazing.</p>
Of course, this is only one part of the puzzle. You also need to incorporate deliberate practice</a>. I drilled the basics, like drawing boxes and doing studies, over and over again. Boring? Yes. Necessary? Absolutely.</p>
But here’s the thing: to stay motivated enough to do all that repetitive, often boring work, you have to focus on the process. If you want to learn to paint—or pursue any creative endeavor—you must learn to enjoy the journey, not just the destination. As you gain skill, activities like painting, dancing, or playing music become more enjoyable because you can create more complex and interesting things. However, the core of what you’re doing remains the same. Whether you’re a beginner or a master, you still sit down with your brushes, mix your paints, and apply them to the canvas. The process is 99% the same, regardless of your level of skill.</p>
So, if you’re serious about getting good at something, focus on the process. Long to do, not just to have done. Embrace the repetitive, the mundane, and the challenging parts of the journey. Love the process, and the end results will follow.</p>

PS: You can find some of my art on my Instagram</a>.</p>

The Plain Text Wiki

2024-08-16T00:00:00+00:00

Every company I’ve worked for has had an internal wiki for essential information, like how to take sick leave, understand the harassment policy, and access other common procedures. Tools like Confluence and SharePoint are popular for this purpose. But what if we took a different approach and used plain text, hosting everything in a Git repository?</p>
Imagine a single repository dedicated to your internal wiki that you can pull down and explore using Obsidian</a>, a powerful note-taking and knowledge management app that stores everything in plain markdown. Not only could you view the content, but you could also easily edit it with Obsidian’s WYSIWYG editor. Avoiding reliance on corporate tools offers significant advantages. When everything is in plain text, you can easily feed it into an LLM to get answers to questions about sick leave or pension plans. Or, if you need to extract some information, you can simply write a Python script. Plus, you can still use your favorite command-line tools like sed</code>, grep</code>, and find</code>. If you want users to have read-only access, you could host the wiki on a subdomain, making it widely accessible while maintaining a detailed history of all changes.</p>
While this approach might not be ideal for most companies, I’d consider it, especially in the early stages when it’s acceptable for only the technical team to manage updates. As the company grows and more people join, for whom learning Git might be too much to ask, we could write a script to push the wiki into a more user-friendly tool.</p>
The larger takeaway is that storing data in a simple format makes it easy to adapt to new situations. If you hand your data over to another company’s tool, you risk getting locked in, making it harder for you and your team to adapt to changing needs.</p>
Note: The inspiration for this blog post came from the excellent YouTube channel No Boilerplate</em> and his video on The Unreasonable Effectiveness of Plain Text</a>.</p>
Be a creator 2024-07-21T00:00:00+00:00 In a world where Netflix, YouTube, and social media constantly vie for our attention, creation offers a way out. The internet, once a boundless creative space, has been split into walled gardens and algorithmically enhanced to capture our focus. You’ve probably found yourself an hour into the future after accidentally opening TikTok, feeling like you’ve wasted time. The solution is to create.</p> My creative journey began at 20 when I realized that I was in control. If I want to eat pancakes every day, I can; I just choose not to. Initially, I procrastinated, and it was difficult to pick up the habit of creation. My GitHub is filled with unfinished projects from my university days, but as my skills grew and the hours piled up, I managed to ignite the fire of creation. At first, it was weak and easily extinguished, but as I fueled it by dedicating an hour each day to painting, it became strong. Very strong. I’ve recently learned to have a bucket of water on hand to prevent it from spreading uncontrollably.</p> Creation brings lasting satisfaction, especially when shared. Cooking and baking are perfect for this and a fantastic opportunity to bring friends and family together. It also lets them give you compliments; nothing is more motivating. Creative things that double as gifts hold a special place in my heart. I’m not a fan of a gift culture built on consumerism and I’m easily bribed with homemade cookies.</p> What will you create? Anything goes! Grilling a steak can be as beautiful as poetry if done with passion. Though different activities have varying skill ceilings, valuing intellectual pursuits over practical skills is flawed. Life is much more beautiful when we view both as acts of creation. I’ve shifted from a passive consumer into an engaged creator: be a creator.</p> Transforming Package Management into a Package Marketplace 2024-06-15T00:00:00+00:00 Introduction</h4> In the world of software development, open-source tools and libraries play a critical role. Yet, the model under which these tools are distributed and maintained often needs to be revised. The “tragedy of the commons” is a prevalent issue, where large enterprises benefit immensely from open-source software without contributing back to its development or maintenance. I believe the issue is the lack of a package marketplace. What if package management tools like Cargo, NPM, and PIP integrated payments directly?</p> The Current Problem</h4> Open-source software (OSS) is foundational to modern software development. However, its free nature often leads to exploitation, particularly by large enterprises that gain significant value without proportional contributions. This imbalance causes numerous problems:</p> Sustainability:</strong> Developers maintaining popular open-source projects often do so without compensation, leading to burnout and abandoned projects.</li> Quality and Security:</strong> Volunteer-maintained projects might lack rigorous quality checks, leading to potential security vulnerabilities and unreliable updates.</li> Innovation Stagnation:</strong> When developers cannot monetize their work, it reduces the incentive to innovate and improve their projects.</li> </ul> What If Packages Were Like a Store?</h4> Imagine a world where downloading packages via tools like Cargo was akin to shopping in an app store. Here’s how this could address the current issues:</p> Benefits</h5> Elimination of Problems like Core-js:</strong> By monetizing packages, developers would be compensated for their time and effort, reducing the likelihood of critical packages becoming unsupported.</li> Diversity and Competition:</strong> A package marketplace would encourage more developers to create and maintain packages, fostering a diverse and competitive ecosystem.</li> Fair Compensation:</strong> Large companies benefiting from open-source packages would be required to pay for the value they receive, ensuring a fair distribution of resources.</li> Improved Security:</strong> With financial incentives, developers would have more resources to invest in thorough testing and security measures, leading to more secure packages.</li> Enhanced Documentation and Developer Experience (DevX):</strong> Monetization would increase the emphasis on high-quality documentation and user experience, as developers would aim to attract and retain paying users.</li> </ol> Potential Challenges</h4> Implementing a package marketplace model for packages will not be without challenges. Key considerations include:</p> Community Resistance:</strong> The open-source community values the freedom and accessibility of current models. Balancing these values with monetization will require careful handling and transparent communication.</li> Transition Period:</strong> Shifting from a free to a paid model might be met with resistance from both developers and enterprises. Phased implementation and clear articulation of benefits will be essential to ease this transition.</li> Economic Disparities:</strong> Ensuring that the pricing structure is fair and does not disadvantage smaller companies or individual developers is crucial. This might require tiered pricing models and thoughtful license structuring. Potential licensing structures include: Pay per Project:</strong> Charges based on the number of projects using the package.</li> Pay Once:</strong> A one-time fee for lifetime access to the package.</li> Pay per Major Release:</strong> Fees applicable for each major update or version released, ensuring ongoing support and development.</li> Scaling Fees:</strong> Different pricing for small startups versus large enterprises to ensure fairness.</li> Service Level Agreements (SLA):</strong> Offering premium support and guaranteed updates for a higher fee.</li> </ul> </li> Integration with Existing Ecosystems:</strong> Ensuring compatibility with existing open-source tools and workflows is crucial for adoption. This might involve creating seamless integrations and offering migration tools to facilitate the switch to the new model.</li> Community and Ecosystem Building:</strong> Cultivating a community around this new model is crucial. Developers need to see the value in monetizing their work, and companies need to understand the long-term benefits of contributing financially to the open-source ecosystem.</li> </ul> Conclusion</h4> The open-source community stands at a crossroads. By reimagining package management as a package marketplace, we can create a healthier, more sustainable ecosystem. This approach not only addresses the “tragedy of the commons” but also incentivizes innovation, security, and quality. It’s time to rethink how we value and sustain the software that underpins our digital world.</p> To bring this vision to life, we need a visionary to develop a new language or package manager with payment as a core feature. Perhaps that someone is you? You won’t need to worry about me; I’ve already got plenty on my plate!</p> Discover History Like Never Before: Timeline's 3.3 Million Events Update! 2024-05-27T00:00:00+00:00 Hello, history enthusiasts!</p> I’m thrilled to announce the release of the 3.3 million events version of timeline</a>! Dive into world history in a fun and interactive way by guessing the order of historical events.</p> About 2 months ago, I embarked on this project with the goal of creating an engaging way to learn about the history of the world. You can read more about my initial motivation in my previous post</a>. Since then, I’ve worked tirelessly to add new features and improve the game, navigating through numerous challenges and redesigns.</p> Initially, I experimented with generating events using AI, but the results were inconsistent. My second attempt involved using the Wikidata SPARQL endpoint, which proved limited. Finally, inspired by Wikitrivia</a>, I downloaded events directly from Wikidata, allowing me to extract a staggering 3.3 million events!</p> While my game shares similarities with Wikitrivia, there are key differences. Wikitrivia has a limited number of events and lacks a tagging system. To address this, I introduced tags and year ranges, enabling players to filter events and create a more personalized experience.</p> My greatest achievement with this project is staying true to my vision: creating a fun and interactive way to learn about world history. I’m incredibly proud of the final product and hope you enjoy playing it as much as I enjoyed creating it.</p> Play timeline</a> and let me know your thoughts. Happy learning!</p> Exercising for life 2024-04-11T00:00:00+00:00 Exercise is a big part of my life. I’ve always exercised since they days my parent enrolled me in the local soccer team. But recently I’ve started to think about it in a different way. Like something that is necessary for my survival. How do I make sure that I exercise until the day I die? I see only one option: make it fun.</p> In my teens I played a lot of handball. I loved the sport and I was pretty good at it. But as I got older I started to lose interest in team sports. I started to go to the gym instead. It was convenient and fit well into my schedule at university but I never really enjoyed it. I did it because I had to, not because I wanted to.</p> If I’m going to exercise until the day I die I need to make it fun. It would be irresponsible to spend such a ridiculous amount of time and not make it enjoyable. So I started trying things. I tried running, dancing, martial arts, and finally I found something that I really enjoy: climbing.</p> Climbing is a great sport. It’s a full body workout (okay, perhaps not that hard on your legs) that is both physically and mentally challenging. It is great to do solo or in a group. It’s a great way to meet new people and it’s a great way to travel. I’ve been climbing for a two years and I still look forward to every session.</p> I could push myself harder and aim for progress, but I’m in no rush. It’s a lifelong pursuit. I plan to exercise until I die so I’m gonna make damn sure I enjoy it.</p> Love tools, hate workflows! 2024-04-11T00:00:00+00:00 You can divide the world of software into two categories: tools, and workflows. Workflows are your enterprise software, your Jira, and your Salesforce. Tools are your text editors, your git, and your terminal.</p> Here is a simple way to differentiate between the two:</p> Tools are used to create things.</li> Workflows are used to manage things.</li> Tools are used by creators.</li> Workflows are used by managers.</li> Tools are used to build.</li> Workflows are used to organize.</li> …</li> </ul> The list goes on.</p> The ultimate goal of a tool is for you to forget that it’s there. You should be able to focus on your work, not the tool. The ultimate goal of a workflow is making sure that everyone is on the same page. It’s about making sure that everyone is following the same process.</p> I hate workflows. I hate them with a passion. I hate them because they are a necessary evil we use to extract the final bit of productivity from our employees. I hate them because they are the reason why we have to fill out forms, attend meetings, and write reports.</p> I love tools. I love them because they are the reason why we can build amazing things. I love them because they empower us all to be creators who can get more stuff done in less time. I love them because they are the reason why we can create art, music, and literature.</p> Make tools, not workflows.</p> GLOW: releasing a game on steam! 2024-04-09T00:00:00+00:00 Hello, people of the internet!</p> I’m in the middle of releasing a game on Steam called GLOW</a>. Here is the description directly from the Steam page:</p> “GLOW is an addictive physics-based arcade game that will challenge you to your limits. Push, dodge, and trick enemies while collecting points as the difficulty increases.</em>”</p> </blockquote> I know what you are thinking: what is the tech stack? Well, I’m glad you asked! The game is built using the Bevy</a> game engine and written in Rust!</p> Here are some of the current pros and cons of using bevy:</p> Pros: Rust</li> Fast</li> Static typing</li> Free</li> Open-source</li> </ul> </li> Cons: Documentation</li> The community is small but very helpful</li> Tutorials are scarce</li> Compile times</li> Unstable API</li> UI is hard</li> </ul> </li> </ul> The main pain points for me have been that Bevy currently has a very lackluster UI system as of 0.13.1</code>. I know there are plans to improve this in the future but for now, it’s a bit of a pain to work with. I’m also losing a lot of time due to lack of hot reloading but that is partly my fault. They recommend not using the release flag in development. Though, since my game is rather simple it hasn’t been a deal breaker. Most of the time I make rather large changes in which case you do not compile that often anyway.</p> The biggest boons for me have been the speed of the engine and the fact that it’s written in Rust. I have been able to write a lot of the game logic in a very safe way. The ESC system is wonderful, combined with algebraic data types, and treating errors as values I have been able to write very robust code.</p> On a personal note, I’ve noticed that I’m gravitating towards tools that are code first. Bevy doesn’t have an editor, instead, everything is written in code. Of course, some things are better done in an editor but programming is my main skill so I’m happy to see this trend. Instead of learning how to use an editor I can reuse my programming skills. A few other tools that are also code-first are Manim</a>, Motion Canvas</a>, and Glicol</a>. Here is an example of a YouTube short I made about 9-slicing images</a> made with Motion Canvas.</p> I’m excited to see where this trend will take us! In the meantime, I hope you will check out my game GLOW</a> on Steam.</p> /Cheers</p> Timeline: Trying to break the internet! 2024-04-09T00:00:00+00:00 Hello, people of the internet!</p> Most likely you stumbled upon this page from playing my game timeline</a> in which case: welcome! I hope you enjoy the game and that you learn something new about the history of the world. For you that didn’t come from the game, I hope you will enjoy the game as well! It’s a fun little project I made where you can learn about the history of the world in a fun and interactive way by guessing the order of historical events.</p> How would a simple web game break the internet you might ask? Well, it probably won’t. But I do believe I have a unique insight.</p> The web, and especially large social media websites like Reddit, is organized into sub-cultures. For example, there is a specific sub on Reddit for pretty much every country. The Swedish sub is called r/sweden</a> and has as of writing 0.7 million members. There is pretty much an infinite number of these subs and they all have their own rules and culture. The insight is that I can create a unique version of the timeline for each of these subs. This would make the game more engaging and also make it more likely that the game would be shared and played by the users of the sub. This is the idea of breaking the internet. In a world of infinite fractal communities, I can create a unique version of the timeline for each of them.</p> Right now I’m only two days into the project and I have already created a basic version. I’m excited to see where this project will take me and I hope you will follow along!</p> You can play timeline here: timeline</a></p> /Cheers</p> My new website 2022-12-25T00:00:00+00:00 Hello, people of the internet!</p> This is the third iteration of my website. I wanted to put a larger focus on my open-source contributions so there is now a projects</a> tab. You’ll find all the NFTs I minted and sold in 2021 at https://nft.frankhampusweslien.com/</a></p> /Cheers</p>

Frank Hampus Weslien

Going Full Agentic

Optimizing the workflow</h4> So the agents work. Now the question is: how do I get more out of them?</p>

Cloud in a box

My Programming Commandments

1. Prefer local state to global state</h3> Global state is that one friend who always crashes on your couch and messes up your stuff. Keep it local whenever possible. Your future self (and your teammates) will thank you.</p>

2. Prefer immutable to mutable</h3> Mutability leads to spooky action at a distance. If something shouldn’t change, don’t let it. Immutable data is predictable, safe, and easier to debug.</p>

3. Prefer composition over inheritance</h3> Inheritance can be a trap. Before you create another subclass, ask yourself: could this be done with composition instead? Most of the time, the answer is yes.</p>

4. Prefer purity to impurity</h3> Pure functions are little islands of sanity in an ocean of side effects. They take input, return output, and don’t mess with the world in between.</p>

5. Parse, don’t just validate</h3> Validating says, “This input is wrong.” Parsing says, “Let’s turn this into something useful.” The latter is way more helpful.</p>

6. Try to make as much as possible run locally</h3> Relying on remote services slows you down. If you can develop, test, or prototype locally, do it.</p>

7. Automate the repetitive stuff</h3> If you’ve done it twice, script it. If you’ve done it three times, make it a proper tool. Your time is too valuable for manual drudgery.</p>

8. Test early, test often</h3> Tests are like seatbelts: annoying until you need them. Write them before you regret not having them.</p>

9. Write code for humans</h3> Code is read way more often than it’s written. Make it clear, make it simple, and make it make sense.</p>

10. YAGNI (You Ain’t Gonna Need It)</h3> That feature you’re “pretty sure” you’ll need later? You probably won’t. Solve today’s problems today.</p>

11. Premature optimization is the root of all evil</h3> Fast code is good, but maintainable code is better. Optimize when it actually matters.</p>

12. Are they similar or are they the same?</h3> Not all duplication is bad. Only share code when changing one part means you must change the other.</p>

13. The Rule of Three</h3> If you see a pattern once, ignore it. Twice? Keep an eye on it. Three times? Now it’s time to refactor.</p>

14. Refactor as you go</h3> Bad code gets written. The trick is to not leave it bad. Refactoring a little at a time prevents big rewrites later.</p>

15. Never fail silently</h3> Silent failures are the worst. If something breaks, scream about it—log it, throw an error, do something! Debugging ghosts is not fun.</p>

Ode to Plain Text

The Art of Code: Sculpting vs Operating

The Secret to Waking Up Well Rested

A new Olympics

What comes after nationalism?

Public Money, Public Code

Why you should long to do, not just to have done.

The Plain Text Wiki

Be a creator

Transforming Package Management into a Package Marketplace

What If Packages Were Like a Store?</h4> Imagine a world where downloading packages via tools like Cargo was akin to shopping in an app store. Here’s how this could address the current issues:</p>

Discover History Like Never Before: Timeline's 3.3 Million Events Update!

Exercising for life

Love tools, hate workflows!

GLOW: releasing a game on steam!

Timeline: Trying to break the internet!

My new website