Forem: Franklin Strube

Free 5-Part Laravel Introduction Series

Franklin Strube — Wed, 04 Feb 2026 17:03:35 +0000

If you're looking to get into app development, Laravel is a great framework that has just about every component you need: models, controllers, auth, background queues, web sockets / broadcasting, and more. There are a lot of resources out there for learning Laravel, and even their docs are top-tier.

Last year, I put together a free five-part series on my blog that introduces Laravel to new developers. It goes a little deeper than the docs, and includes tips for troubleshooting some common errors that may hinder a beginner.

Hopefully these articles can help you if you're a beginner and want to give Laravel a try!

Are you working from home? Chances are you're doing it wrong.

Franklin Strube — Mon, 19 Jan 2026 07:23:23 +0000

In a recent blog about the benefits of co-working, I outline seven reasons why you should get out of the house and co-work with friends, family, or even strangers.

Is Omarchy Any Good...?

Franklin Strube — Mon, 19 Jan 2026 06:59:24 +0000

In case you've been living under a rock, you've probably heard the buzz about Omarcy Linux (the new-ish Linux distro that is the brainchild of 37signals co-founder, David Heinemeier Hansson). I've been slowly rolling it out across my home systems, and blogging as I go.

What are the good parts of Omarchy?

First and foremost, the look-and-feel of the operating system is superb. You can really tell that the team behind the project have spent a good deal of time on making things minimal yet robust.

All aspects of the operating system are accessed primarily by keyboard shortcuts (and mouse clicks in just a few cases). I like this, especially because I do a lot of work on a laptop.

Being based on Arch Linux means you have thousands upon thousands of software applications at your fingertips. I've been able to install development environments, docker containers, and retro games without any problems.

I've found that Omarchy can breathe new life into old hardware. The desktop environment runs on very minimal resources. Window management is snappy, and as long as you're not running resource-intensive applications then you're fine.

Let's talk tiling window managers...

I know, they're kind of a polarizing topic. It's a first for me, but now that I'm used to the keyboard shortcuts it feels pretty natural. I think if you have a large monitor it makes a difference, especially when working with multiple windows.

One thing that I think would be nice is the ability to hide a window without closing the application. It would be a helpful way to manage your screen real-estate.

Where does Omarchy fall short?

So far I'm zero-for-two on running the Omarchy update tool. First one bricked my desktop, and I had to restore from backups. Second nearly bricked my laptop. I had to login from a bootable USB and arch-chroot then reinstall the Linux kernel.

The verdict

Despite some rough edges, Omarchy is a compelling experiment in thoughtful operating system design. It feels opinionated in a good way: focused, fast, and built for people who live on their keyboards and value simplicity. If you enjoy tinkering, don’t mind getting your hands a little dirty when things go sideways, and want a Linux environment that feels both modern and intentional, Omarchy is well worth trying.

You can read more about my Omarchy journey over at franklinstrube.com:

Introducing Frak.js: Simple, Scriptable Code Deployments

Franklin Strube — Tue, 13 Jan 2026 03:42:07 +0000

Frak.js is a rewrite of an internal tool we’ve relied on at work for years, rebuilt from the ground up with a single goal: make server administration simple, repeatable, and boring in the best way possible.

At its core, Frak.js uses two battle-tested tools you already trust:

ssh for running commands on remote machines
rsync for efficiently copying files to those machines

No agents. No background daemons. No magic.

Getting started is intentionally boring:

npx @frakjs/frak init

That’s it. No global installs, no configuration rabbit holes. You’re up and running in seconds.

Why Frak.js Exists

Most deployment and server management tools fall into one of two categories:

Too heavy — full configuration management systems that require learning an ecosystem, installing agents, and maintaining state.
Too ad hoc — shell scripts and one-off commands that work until they don’t, then slowly drift into chaos.

Frak.js sits intentionally in the middle.

It assumes:

You’re comfortable with SSH access
You want explicit control over what runs and where
You don’t want to reinvent the same deployment scripts for every project

Frak.js doesn’t try to model your infrastructure. It helps you operate it.

How It Works (Conceptually)

A Frak.js workflow typically looks like this:

Define what files should be synced to a remote server
Define what commands should run before or after that sync
Execute the workflow against one or more servers

Under the hood:

rsync handles file transfers efficiently
SSH executes commands remotely
Frak.js coordinates the order, structure, and repeatability

The result is a clear, auditable process that can live alongside your codebase.

Use Case 1: Hobby Projects and Side Projects

If you’ve ever deployed a personal project by:

SCP’ing files manually
SSH’ing in and running commands by memory
Hoping you didn’t forget a step

Frak.js is for you.

With a simple configuration, you can:

Sync your app to a VPS
Restart services
Run migrations or setup scripts

This makes deploying a hobby project feel intentional instead of fragile—without introducing heavyweight tooling that feels disproportionate to the project.

Use Case 2: Raspberry Pi and Home Servers

Raspberry Pi setups are notorious for being:

Manually configured
Poorly documented
Hard to reproduce after “just one more tweak”

Frak.js works well here because it:

Requires nothing running on the Pi except SSH
Lets you codify setup steps and updates
Makes it easy to manage multiple devices consistently

Whether you’re running a home media server, a Pi-hole, or a small cluster of devices, Frak.js gives you a repeatable way to apply changes without turning your home lab into a snowflake.

Use Case 3: Production Environments

Frak.js was born out of real production usage, and it shows.

For small teams or focused services, it can:

Deploy application updates
Run controlled administrative commands
Serve as a transparent alternative to opaque CI/CD magic

Because it relies on SSH and rsync, it integrates cleanly into existing security models and operational practices. There’s no black box—just clear steps you can reason about and debug.

Built to Be Understandable

One of the guiding principles behind Frak.js is clarity over cleverness.

You should be able to:

Read a Frak.js configuration and understand exactly what will happen
Run it locally without special infrastructure
Trust that it’s doing only what you told it to do

It’s not trying to replace Kubernetes, Terraform, or Ansible. It’s for the space where those tools feel like too much—and where shell scripts feel like too little.

What’s Next

Frak.js is still evolving, but its foundation is deliberately simple. If you:

Deploy code over SSH
Manage small-to-medium servers
Value explicit, repeatable workflows

…then Frak.js may already fit naturally into how you work.

More documentation, examples, and real-world workflows are coming soon.

See github.com/frakjs/frak

Always Version-Control Your Lock Files

Franklin Strube — Thu, 24 Jul 2025 21:08:12 +0000

It misses the whole point of version-control if you're not adding your lock files (yarn.lock, package-lock.json, or composer.lock) to your repos. Think about it this way: there should be as few steps as possible between git checkout and a fully functional version of your app. It's totally acceptable to defer version-controlling lock files until a release is published, but whatever your version-control strategy, it should include the lock files, for sure.

The same goes for build assets in public/build or similar location. If you're doing the build in a CI/CD pipeline, that's fine. Just make sure there is a "source of truth" and an audit trail that verifies the assets are authentic. Version-controlling with git is the perfect way to do it.

So remove yarn.lock from .gitignore, and don't look back.

🔐 Securing Data at Rest and In Transit: A Practical Overview

Franklin Strube — Fri, 11 Jul 2025 02:30:38 +0000

Computer security is slippery—vulnerabilities exist from firmware to frontend. If you’re storing or moving sensitive data, your best bet is a layered approach. Here’s how to think about securing data at rest and in transit in real-world systems.

💾 Data at Rest

Data at rest lives in databases, disk storage, backups, etc.

✅ Encrypt everything

Use AES-256 or similar.
Full-disk encryption + field-level encryption where needed.

✅ Tighten access control

Least privilege for users and systems.
Enforce RBAC or ABAC.

✅ Protect your keys

Use a key vault (e.g., HashiCorp Vault, AWS KMS).
Rotate regularly. Don’t hardcode secrets.

✅ Log and monitor

Track who’s reading/writing sensitive data.
Set alerts on anomalies.

🌐 Data in Transit

Data in transit flows over networks—between clients, services, APIs.

✅ TLS everywhere

Use TLS 1.2+ with strong ciphers.
Validate certs. Avoid self-signed in prod.

✅ End-to-end encryption

Especially for messaging/P2P apps.

✅ Secure internal communication

Use VPNs, service meshes, or zero-trust networking.
Don't blindly trust internal IPs.

✅ Defend the app layer

Input validation, CSRF/XSS protection, rate limiting.

🧱 TL;DR: Defense in Depth Wins

You won’t stop every attack. But you can:

Minimize the blast radius 🔥
Detect problems early 🔍
Make breaches expensive and noisy 💸

Security isn't a checkbox—it's a mindset.

Want the full post? Head on over to franklinstrube.com

The AI Surge: How Large Language Models Are Transforming the Way We Code

Franklin Strube — Tue, 08 Jul 2025 06:20:59 +0000

Artificial Intelligence (or Large Language Models, if we're being specific) are all the rage these days. What started as a novelty—AI generating poems, jokes, or essays—has rapidly evolved into a transformative force in software development. Not only can AI write fluent, coherent English, it can now write code at a blistering pace.

Gone are the days of scouring Stack Overflow for the right snippet. Today, developers are pairing up with machines that understand natural language, anticipate intent, and fill in the blanks—literally—as they type. Editors like Cursor, Windsurf, and Claude are leading the charge, offering autocomplete on steroids. They predict what you’ll write next—sometimes before you’ve even thought of it.

From Auto-Complete to Co-Creation

Traditional autocomplete tools simply finished off function names or suggested common syntax patterns. But tools built on LLMs (like GPT-4, Claude, or proprietary models from Anthropic and Google) go several steps further. They're context-aware, project-savvy, and increasingly capable of:

🔨 Refactoring legacy code

🚨 Writing tests with minimal prompts

🐞 Debugging errors and suggesting fixes

📝 Translating code between languages

📚 Explaining code to junior developers

🔥 Prototyping entire features from a description

It's not just autocomplete anymore—it's co-creation. The best tools feel less like assistants and more like collaborative partners.

The New Development Workflow

Let’s face it: most developers today don’t write code line-by-line from memory. They Google. They copy-paste. They iterate. Now, with LLMs baked into their editors, the cycle becomes even faster. You describe what you want—sometimes vaguely—and the AI offers a complete, executable solution.

Need a REST API endpoint in Express.js? Describe it in plain English, and it’s done. Want a SQL query to handle a gnarly recursive relationship? The AI has likely seen thousands and will generate one instantly. Even the initial drafts of pull requests are being written by machines.

Limitations and a Word of Caution

Of course, this isn’t a silver bullet. AI-generated code can still be buggy, inefficient, or even insecure. The LLM doesn’t “understand” code the way a human does—it mimics patterns it has seen before. Blind trust in its output can be risky.

That’s why human oversight, testing, and code review are more essential than ever. Think of AI as a junior dev with infinite energy and no ego—great at suggesting ideas, not so great at making judgment calls.

What’s Next?

As LLMs become more tightly integrated into IDEs and CI/CD pipelines, the nature of software development will continue to shift. Writing code will look more like designing systems and expressing intent—and less like grinding through syntax and boilerplate.

It’s an exciting time to be a developer. The tools we use are becoming more powerful, more contextual, and more conversational. We're not just writing code anymore—we're collaborating with machines that can help us think faster, build smarter, and dream bigger.

Dopamine-Driven Development: Why That "It Works!" Moment Feels So Good

Franklin Strube — Fri, 06 Jun 2025 02:25:02 +0000

✅ Identify the challenge
✅ Write code
✅ It works!
🧠 Brain reward system activated
🚀 Confidence skyrockets

This is Dopamine-Driven Development.

If you've ever felt a rush of excitement when your code finally works—congratulations, you've experienced Dopamine-Driven Development (3D). It's that unmistakable high when a feature clicks into place, the test turns green, or a clever one-liner does exactly what you hoped. For many developers, these little victories are what keep the momentum going day to day.

Software engineering is often framed as logical, analytical work. But behind the scenes, it’s a deeply emotional experience. When we face down a bug, a blank screen, or a complex architectural problem, we’re not just engaging our brains—we’re triggering our reward system. Every time we overcome a challenge, dopamine gets released, reinforcing the behavior. That’s why even small wins, like successfully refactoring a function or improving performance by 2%, can feel disproportionately satisfying.

Of course, this can cut both ways. The pursuit of that dopamine hit can lead to shortcuts, like skipping documentation or ignoring edge cases just to see something “working.” That's where discipline and balance come in—acknowledging the value of these feel-good moments, but also remembering to pair them with sustainable practices like testing, reviewing, and planning.

Dopamine-Driven Development isn't a bad thing—it’s one of the quiet motivators that keeps us curious, engaged, and pushing through the hard parts. So go ahead, celebrate that passing test. Just don’t forget to delete all those console.logs 😎.

JavaScript is so redundant

Franklin Strube — Tue, 03 Jun 2025 02:39:28 +0000

Why are there so many JavaScript build tools? Gulp, Grunt, Webpack, Laravel Mix, Rollup.js, and now Vite. And these are just the ones that I've worked with. Haven't we solved this problem? And why build a new tool? Why not improve existing tools?

I think about predecessors like GNU Make. Sure, it's old, but it's tried and true. The invocation is consistent and has been for years: make [command].

How different would the world be if the Node.js ecosystem adopted Make as the preferred mechanism for running scripts, instead of npm run [command]? I guess we'd be seeing a lot more Makefile's around.

I built a Markdown editor and preview tool in 2025 with NO Copilot

Franklin Strube — Thu, 13 Mar 2025 02:15:22 +0000

It's 2025 and the year of vibe coding. You reach for your favorite AI and let it run wild while you chill in between prompts. If I were a smart man, I would jump on the bandwagon. But for some reason I'm lagging behind on this one.

I recently started a side project (slickpdf.com), and was able to launch it completely without AI. Full stack, no AI was used in the creation of the project. Not that this is an accomplishment or anything. Honestly, it's more of a confession. AI greatly reduces overhead, especially when starting from scratch. I could've had Copilot scaffold my landing page, or asked ChatGPT to flesh out my app UI using PrimeVue. These steps would've saved me hours of work. But no, instead I opted for the hand-written approach of yesteryear. True, it's thrilling, and I like the control of knowing that I wrote and inspected every line of code. But I'm left to wonder how much faster I can ship with a little sprinkle of the AI pixie dust.

Anyways, don't forget what you're capable of without AI. Remember that it's a tool to make you better at something you're already good at. It augments your existing skills.

How to convert Markdown to PDF

Franklin Strube — Mon, 24 Feb 2025 04:36:14 +0000

There are a million and one document formats out there that all seem to do one thing or another. However, I've found that simplicity is key. You want something that is simple to read under-the-hood, but predictable when presented on screen.

Avoid classic word-processors like MS Word

Document formats like MS Word are risky because, while universal, they are subject to things like text re-flow, especially when opened in different environments (either the fonts are missing or don't work, or your word processor renders the content differently compared to mine).

PDFs are known for being consistent

PDF is a bullet-proof format when it comes to display, and when created properly, it embeds fonts so that it will always be rendered perfectly on any machine. However, PDF documents under-the-hood aren't quite that readable by human eyes.

Markdown is a simple text-based format

Enter Markdown. Markdown is a format that is human-readable. Paragraphs are simply lines of text. Headings begin with a single #-sign or more. Bold text is surrounded by stars like **this**. It's just easy on the eyes.

Markdown to PDF is a powerful workflow

Typically, Markdown is converted to HTML in order to be formatted for the web. This is great, but what if you're not serving the Markdown via a browser? If you're a student, you may be required to turn in a PDF of your assignment. What if you want to generate a PDF so you can publish a book? By writing your documents in Markdown and converting them to PDF, you get the ease of writing text plus the ubiquity of displaying a PDF. It's a great workflow for publishing printable media.

How do you convert Markdown to PDF?

There are a handful of excellent command-line tools, and Pandoc comes to mind. It is not just a one-trick pony, too. With Pandoc you can convert between many different formats.

Another option is to go with a purpose-built tool, like SlickPDF. I built slickpdf.com for the very purpose of going from Markdown to PDF. Give it a try!. It uses marked.js under the hood, and presents a live preview rendered on a Letter-size (8.5 in. x 11 in.) page.

Conclusion

So the next time you need to publish a PDF either for school, or for work, or just for fun, consider writing it in Markdown. You'll get the ease of "just typing" and a beautiful end product.

Think about all the greats that came before you.

Franklin Strube — Mon, 17 Feb 2025 17:51:40 +0000

I think often about the course of history in computing, and find myself in awe of our accomplishments as a community. It's innovation at a rapid pace, to say the least.

Have you ever wondered just how much is possible due to the work those that came before you? Think about something as seemingly mundane as text encoding. The design of Unicode is something of genius.

Or take, for instance, the PDF. A document format that pre-dates the rise of the Internet and still thrives to this day. The PDF reference is itself a PDF. How meta is that?!

This is why I love building in public. Because it connects people accross the world through a common interest in improving the status quo. So, maybe on this holiday, think of one thing you take for granted in the computing space and dig a little bit into its history. You may find inspiration along the way.

Happy coding!