DEV Community: Pedro Pablo Camellon

Migrating My Portfolio to Jekyll: Why and How

Pedro Pablo Camellon — Thu, 16 Apr 2026 19:33:06 +0000

My original workflow was simple by design. I'd write in Notion, leverage Notion AI for faster edits, publish the page, and embed a link to it from my site. The blog itself was just HTML, CSS, and JavaScript—intentionally minimal. This kept the code clean and gave me more time to write.

But over time, I realized I was too dependent on Notion. My content lived in their database. Every post was a published Notion page that I linked to. If Notion went down, my blog was broken links. I had no version control over my content. No history of edits. No way to track how my writing evolved.

I wanted my content in Git, tracked natively alongside my code. Markdown felt like the obvious choice—simple, portable, perfect for technical writing.

Why Jekyll?

I was already using GitHub Pages for hosting. Jekyll has native, out-of-the-box support there. No configuration. No build pipelines. Just push markdown files and it works. That alone was compelling.

But the real reason? Jekyll is mature. It's been around since 2008. The ecosystem is stable. The documentation is thorough. I didn't want to spend time fighting a new framework or debugging alpha-stage tooling. I wanted to write.

Markdown as source of truth. My content lives in Git now. Every post is a markdown file. Every edit is a commit. I can track how my writing evolved, roll back mistakes, and branch for experiments.

Native GitHub Pages integration. Push to main and it's live. GitHub handles the build. No CI/CD config needed. No deployment scripts. It just works.

Static site generators made sense. My blog was already static HTML. Static site generators are perfect for this—fast, simple, and well-suited for content-focused sites.

Automated everything. Posts sort themselves by date. Tags display automatically. Excerpts appear in blog cards but not in articles. The "NEW" badge shows up based on a simple frontmatter flag.

Keep it minimal. I didn't want framework hacks. No endless plugin dependencies. No complex build setups. Jekyll lets me focus on writing, not on tooling. The site does one thing well: display markdown content.

The Migration Journey

The migration happened in phases over a weekend. My old site was intentionally simple—HTML, CSS, JavaScript. Blog posts were just links to published Notion pages. Clean, but not sustainable.

I started by setting up Jekyll's basic structure—a _config.yml file, a simple Gemfile, and the essential _layouts/default.html template. That template became the heart of the site, handling navigation, analytics, and the footer for every page.

Next came the CSS. I kept it minimal. Two focused files: main.css for base styles (typography, navigation, code blocks, tables) and pages.css for components (hero section, blog cards, responsive design). No frameworks. No bloat. Just what I needed.

The blog list transformation was where Jekyll really shined. What used to be manual HTML became a simple Liquid template that filters, sorts, and displays posts automatically. Jekyll handles the heavy lifting—I just write markdown.

Migrating 20+ existing posts from Notion could have been tedious, so I automated it with a PowerShell script. The script extracts excerpts, adjusts heading levels, renames images with descriptive prefixes, and generates consistent frontmatter. What would have taken days took an afternoon. That was the last time I pulled content from Notion.

Now, I still brainstorm in Notion—it's great for messy thinking. But when it's time to write, I open VS Code, create a markdown file, and the content lives in Git from day one.

Even the projects page got simpler. Instead of maintaining an HTML table with inline styles, I converted it to markdown with badge-style GitHub and blog links. Jekyll's built-in table rendering handled the rest.

You can see all the code in the GitHub repository—it's cleaner than any tutorial could show.

The Frontmatter Philosophy

Every blog post now starts with consistent frontmatter that tells Jekyll everything it needs to know:

---
layout: default
title: "Article Title"
date: 2026-04-07
tags: ["web-dev", "jekyll"]
image: "thumbnail.webp"
excerpt: "One-sentence summary for blog cards"
---

The date field controls sorting. The is_new flag shows the "NEW" badge (I remove it after a few weeks). The excerpt appears only in blog cards, never in the article itself. It's metadata-driven content management at its simplest.

Local Development: Docker Saves the Day

Setting up Ruby environments can be painful. Version conflicts, gem dependencies, platform-specific issues—it's a rabbit hole. Docker solved all of it.

I created a simple docker-compose.yml that spins up Jekyll 4.2.2 with live reload. No Ruby installation needed. No version conflicts. Just docker compose up and start writing. The development server runs at localhost:4000 with instant preview of changes.

The only hiccup? SSL certificate errors when Docker tried to fetch gems from https://rubygems.org. The fix was simple: change the Gemfile source to http://rubygems.org. Not ideal for production, but perfectly fine for local development.

Deployment: Git Push and Forget

The deployment workflow is delightfully simple. Edit files locally. Commit changes. Push to the main branch. GitHub Pages automatically builds and deploys the site. I don't even commit the _site/ build directory—GitHub handles it server-side.

For preview environments, I set up a GitHub Actions workflow that deploys the dev branch to a separate URL. It's useful for testing major changes before they go live.

What I Learned

Convenience can become dependency. Embedding Notion links was easy. Too easy. I traded control for convenience and didn't realize it until I wanted my content in Git.

Maturity matters. Jekyll isn't the newest or flashiest static site generator. But it's battle-tested. The documentation is solid. The ecosystem is stable. That's worth more than cutting-edge features.

Keep it minimal to focus on writing. I could have added a dozen frameworks and plugins. But every dependency is a potential distraction. Minimal tooling means more time writing, less time debugging.

Notion for brainstorming, Git for publishing. Notion is still valuable for messy thinking. But polished content belongs in version control. Separate the tools, keep both useful.

Docker is worth the setup. I avoided days of Ruby environment troubleshooting by starting with Docker. The consistency across machines is invaluable.

Automation compounds. That PowerShell import script saved hours on the initial migration. But more importantly, it'll save hours every time I import new posts. Time spent on automation is time invested.

Frontmatter is powerful. Separating metadata from content keeps everything clean. Tags, excerpts, dates, badges—all controlled through simple YAML fields.

Static site generators are perfect for blogs. My site was already static HTML. Jekyll just formalized it. Fast, simple, and perfectly suited for content-focused sites.

The Results

Before: Write in Notion → Publish Notion page → Embed link in site → Hope Notion stays up.

Now: Write markdown → Commit to Git → Push. Done.

My content is version controlled. Every post has edit history. The site is faster (no external dependencies on Notion). And I'm not locked into one platform anymore.

More importantly, I'm writing more. The friction of "where does this content live?" is gone. Markdown files in Git feel right. The mental overhead vanished.

What's Next?

I'm keeping a list of potential enhancements—search functionality, pagination, dark mode, WebP image optimization as a part of the GitHub Action, reading time estimates. But I'm not rushing. The site works. It's minimal by design. Every feature I don't add is one less thing to maintain.

So far, keeping it minimal has been the right choice. I'm focused on writing, not on framework hacks. That was the whole point.

Resources

GitHub Repository: pedropcamellon.github.io
Jekyll Documentation
GitHub Pages + Jekyll Guide
Liquid Template Language
Testing Your GitHub Pages Site Locally with Jekyll

-
Originally published here: https://pedropcamellon.github.io/blog/2026-04-07-migrating-portfolio-to-jekyll/2026-04-07-migrating-portfolio-to-jekyll.html

Orchestration vs Choreography: Two Ways to Build Clinical Speech-to-Text

Pedro Pablo Camellon — Thu, 16 Apr 2026 19:30:49 +0000

I built clinical transcription twice — once with event-driven choreography on AWS, once with workflow orchestration in Folium EHR. I wrote about the first approach in the Medical Calls Analysis series.

The core insight: choreography and orchestration are not the same thing. I used to mentally lump them together as "async" until I built both and felt the tradeoffs up close. The difference matters a lot more when you're handling clinical data.

Two Patterns for Async Work

Before getting into the specifics, it's worth naming the two patterns clearly.

Choreography (event-driven): each service reacts to events independently. No central coordinator. S3 emits an event, Lambda picks it up, writes to S3, another Lambda picks that up. Each service knows its own job and nothing else. The "workflow" is an emergent property of events flowing between services.

Orchestration (workflow-driven): a central coordinator defines the steps, owns the state, and controls the sequence. Each step is an explicit function call. The workflow is the code — one file, readable, testable, versionable.

Both are valid. They optimize for different things.

The Choreography Approach

The AWS pattern for clinical transcription is well-established. S3 event → Lambda → Transcribe → S3 → Lambda → Bedrock → S3. Fully managed. Scales to zero. Costs almost nothing at low volume. I built a version of this in the Medical Calls Analysis series.

Choreography is a solid default for a lot of systems.

But think about what happens when a Lambda times out mid-pipeline. The message hits the DLQ. No alarm fires. Nobody notices for hours. A clinician's notes from that morning are just... gone. No error surface, no visible status, no obvious place to even start looking.

To debug it, you correlate CloudWatch logs across three Lambda functions, check the SQS DLQ, inspect S3 prefixes, and piece together what happened from timestamps.

That's the fundamental tradeoff of choreography: there's no centralized state. Each service knows its own slice. Nobody knows the full picture of a single job. To answer "where is this transcription right now?" you have to ask five different systems and hope the correlation IDs line up.

Choreography gives you decoupling and independence. It takes away visibility and coordinated failure handling.

The Tradeoffs

I don’t think orchestration is “better” in a vacuum. It comes with real costs and tradeoffs, and in a lot of systems choreography is the right call.

Where choreography tends to win

Infrastructure: Fully managed primitives (S3, Lambda, SQS)
Cost at low volume: Nearly free (pay-per-invoke)
Getting started: Wire an event and ship it
Coupling: Services are decoupled by default
Failure blast radius: Distributed. One function timing out does not pause the whole system

Where orchestration tends to win

Failure visibility: Built-in workflow history and status
Retry control: Per-step retries with backoff and error classes
Debugging: You can inspect one workflow run instead of correlating logs across services
State: Centralized state for a single job ("where is this transcription right now?")

One tradeoff that’s easy to underestimate: with orchestration, the coordinator is load-bearing infrastructure. If it goes down, workflows pause until it comes back. With choreography, failures are more distributed by design.

Orchestration engines also enforce constraints that can trip you up at first. In Temporal, workflow code must be deterministic (no random numbers, no direct I/O, no datetime.now()). Side effects go in activities, coordination goes in workflows.

A small but important implication: if the workflow fails during step 2, the engine retries step 2. Steps 1 and 3 do not re-run. That is deterministic replay in practice.

This annoyed me at first. Then I realized it forces a clean separation I'd want anyway: coordination logic vs. real work. It's just good architecture with the engine enforcing it.

But if your team has never worked with orchestration engines, budget real ramp-up time. The mental model is genuinely different from event-driven.

Why Healthcare Tips the Scale Toward Orchestration

In most domains, choreography's tradeoffs are acceptable. A lost analytics event or a delayed notification isn't catastrophic.

Healthcare is different.

A lost transcription is a lost patient encounter. A Lambda timeout mid-pipeline can mean the message hits the DLQ, no alarm fires, and nobody finds out until a clinician reports missing notes. That's not a bug report. That's a compliance incident.

Orchestration gives you an audit trail by default. Every event logged, every state transition queryable. HIPAA wants to know where PHI flows and who touched it? It's in the workflow history. In a choreographed setup, building an equivalent audit trail is a separate project — one that's easy to deprioritize until you need it.

The "async trap" is real: choreography gives you non-blocking execution but not durability. A crashed function can lose its in-flight job. A crashed orchestration worker is just a pause. The workflow picks up on the next available worker.

In healthcare, durability isn't a nice-to-have. It's the whole point.

What I'd Do Differently

Polling for transcription status is the current approach in Folium. WebSocket push would cut latency and reduce server load. That's the natural next step.

I'd also formalize workflow IDs around patient encounter IDs from day one. Orchestration workflows are naturally idempotent when keyed to a business ID. Start the same workflow ID twice and the engine just returns the existing run.

The Bottom Line

For multi-step AI workflows where failures matter, I’ve found orchestration to be the better fit. The visibility and durability are hard to replicate in a choreographed system, and in healthcare those properties matter a lot.

For a simple event trigger (thumbnail resize, log processor, webhook relay), choreography is usually simpler, cheaper, and perfectly fine when losing one event isn’t the end of the world.

The mistake is treating these as the same category. "Async" is not one thing. Choreography and orchestration solve different problems. I learned that by building the same system twice.

Resources

Temporal docs: https://docs.temporal.io/
Temporal Concepts (workflows, activities, determinism): https://docs.temporal.io/concepts
AWS Serverless Event-Driven Architecture patterns: https://docs.aws.amazon.com/whitepapers/latest/serverless-architectures-lambda/serverless-architectures-lambda.pdf
AWS SQS DLQ docs: https://docs.aws.amazon.com/AWSSimpleQueueService/latest/SQSDeveloperGuide/sqs-dead-letter-queues.html

--
Originally published at pedropcamellon.github.io