240 lines
30 KiB
PHP
240 lines
30 KiB
PHP
<?php
|
||
return [
|
||
'name' => 'Juvenal Diaz',
|
||
'job_title' => 'Senior DevOps / MLOps / Platform Engineer',
|
||
'contacts' => 'Contacts: +52 449 217 6833, juvenaldiaz522@gmail.com',
|
||
|
||
'nav_home' => 'Home',
|
||
'nav_cv' => 'CV',
|
||
'nav_blog' => 'Blog',
|
||
'nav_demos' => 'Demos',
|
||
|
||
'bio_intro' => 'I help teams keep important software running, make releases less stressful, and turn repeated problems into clear, repeatable work.',
|
||
'bio_story_1' => 'I am based in Aguascalientes, Mexico, and I am focused on senior remote roles where calm ownership, practical judgment, and follow-through matter.',
|
||
'bio_story_2' => "Over 12+ years, I have supported customer-facing services, internal engineering platforms, and teams that needed reliable systems more than buzzwords.",
|
||
'bio_story_3' => 'This site shows that style directly: real homelab work, clear case studies, and small demos that explain how I think about dependable delivery.',
|
||
'bio_cta' => 'Start with the case studies, browse the demo shelf, or read the full',
|
||
'bio_cta_link' => 'CV',
|
||
|
||
'home_cta_cv' => 'View CV',
|
||
'home_cta_cases' => 'Read case studies',
|
||
'home_cta_mlops' => 'Future AI platform demo',
|
||
'home_cta_email' => 'Email me',
|
||
'home_proof_kicker' => 'What I bring',
|
||
'home_proof_title' => 'Calm, practical platform work for remote teams',
|
||
'home_proof_platform_label' => 'Delivery',
|
||
'home_proof_platform_title' => 'Shipping with less friction',
|
||
'home_proof_platform_body' => 'I care about making changes traceable, repeatable, and easier to recover when something goes wrong.',
|
||
'home_proof_scale_label' => 'Production',
|
||
'home_proof_scale_title' => 'Reliability under pressure',
|
||
'home_proof_scale_body' => '12+ years keeping real services healthy for internal teams and external customers, including incidents, maintenance, and support.',
|
||
'home_proof_mlops_label' => 'Direction',
|
||
'home_proof_mlops_title' => 'Production-minded AI work',
|
||
'home_proof_mlops_body' => 'The next demo will show how I would run a small model service with monitoring, safe rollout, and rollback. The focus is operations, not research.',
|
||
|
||
'cv_summary_title' => 'Professional Summary',
|
||
'cv_summary' => 'Senior infrastructure and reliability engineer with 12+ years of experience across Linux, Kubernetes-based platforms, cloud operations, incident response, automation, and production support. Currently operating a Kubernetes/Terraform PaaS used by 20,000+ internal developers, with hands-on work in maintenance, emergency changes, tooling, documentation, GitOps-style delivery, and continuous improvement. Targeting senior remote DevOps, SRE, platform, and MLOps roles where reliability, automation, and clear operations matter.',
|
||
'site_theme_label' => 'Theme',
|
||
'site_theme_dark' => 'Dark',
|
||
'site_theme_light' => 'Light',
|
||
'cv_theme_label' => 'Theme',
|
||
'cv_theme_elegant' => 'Dark',
|
||
'cv_theme_fancy' => 'Light',
|
||
'cv_orbit_text' => 'Kubernetes, Terraform, Linux, SRE, automation, observability, GitOps, and MLOps platform work.',
|
||
|
||
'cv_impact_title' => 'Impact Snapshot',
|
||
'cv_impact_1' => '20,000+ internal users supported through a Kubernetes/Terraform platform as a service.',
|
||
'cv_impact_2' => '10,000+ external Oracle Analytics customers supported through incident response, Linux troubleshooting, SQL tuning, automation, and runbook work.',
|
||
'cv_impact_3' => '4M+ requests per minute and 30+ microservices supported on a PCI-compliant platform using containers, orchestration, alerting, and DevOps practices.',
|
||
'cv_impact_4' => 'Top performer history across Oracle and Rackspace teams, with onboarding, automation epics, and on-call process improvement work.',
|
||
'cv_skills_title' => 'DevOps / SRE / MLOps Skill Matrix',
|
||
'cv_skill_platform_title' => 'Platform engineering',
|
||
'cv_skill_platform_body' => 'Kubernetes, kubeadm, Helm, Argo CD, Kyverno, OpenTofu/Terraform, Docker Buildx, local registries, Linux, container runtimes, storage, and worker placement.',
|
||
'cv_skill_sre_title' => 'SRE and operations',
|
||
'cv_skill_sre_body' => 'Incident response, emergency changes, planned maintenance, monitoring, alert tuning, Prometheus, Grafana, Loki, node-exporter, runbooks, RCA, and ITIL process experience.',
|
||
'cv_skill_automation_title' => 'Automation and delivery',
|
||
'cv_skill_automation_body' => 'Bash, Python, Ansible, REST APIs, GitOps delivery loops, Gitea Actions, Bitbucket workflows, secret scanning, image scanning, and repeatable infrastructure scripts.',
|
||
'cv_skill_mlops_title' => 'MLOps direction',
|
||
'cv_skill_mlops_body' => 'FastAPI inference service patterns, model metrics, drift detection, canary/rollback workflows, model-serving platform design, MLflow/KServe/Ray learning path, and Kubernetes-based ML operations.',
|
||
'cv_recruiter_title' => 'Remote Work Fit',
|
||
'cv_recruiter_1' => 'Based in Aguascalientes, Mexico and focused on remote senior/staff opportunities with global engineering teams.',
|
||
'cv_recruiter_2' => 'Best-fit roles: Senior DevOps Engineer, Senior SRE, Senior Platform Engineer, Infrastructure Engineer, or MLOps Platform Engineer.',
|
||
'cv_recruiter_3' => 'Open to direct hire, employer-of-record, or contractor engagement for USD-aligned remote roles.',
|
||
|
||
'cv_employment_title' => 'Employment History',
|
||
|
||
'cv_job1_period' => 'Aug 2024 → Current',
|
||
'cv_job1_title' => 'Site Reliability Developer – Oracle | Spectra',
|
||
'cv_job1_desc' => 'Operate a Kubernetes/Terraform platform as a service that lets 20,000+ internal developers build, run, and operate cloud applications. Daily work includes planned maintenance, emergency changes, tooling improvement, documentation, operational guardrails, and reliability-focused platform support.',
|
||
|
||
'cv_job2_period' => 'June 2022 → July 2024',
|
||
'cv_job2_title' => 'Site Reliability Developer – Oracle | Analytics',
|
||
'cv_job2_desc' => 'Resolved Oracle Analytics Cloud incidents for 10,000+ external customers, including Linux troubleshooting, SQL query tuning, service/job configuration, and usage issues. Built internal automation with Bash, Python, Ansible, and REST APIs, maintained SOPs, led continuous improvement and automation epics, supported new-hire onboarding, and proposed on-call rotation improvements.',
|
||
|
||
'cv_job3_period' => 'July 2021 → June 2022',
|
||
'cv_job3_title' => 'Linux Support Engineer - Rackspace',
|
||
'cv_job3_desc' => 'Handled multi-client Linux incidents through phone and ticketing channels across MySQL, Apache, NGINX, Varnish, PHP, VMware, DoS events, storage, backups, and firewalls. Ranked as a top performer by case volume across MX and US teams and helped onboard new hires.',
|
||
|
||
'cv_job4_period' => 'March 2020 → July 2021',
|
||
'cv_job4_title' => 'Linux Support Engineer - Softtek | Electronic Arts',
|
||
'cv_job4_desc' => 'Provided infrastructure support for a PCI-compliant platform handling 4M+ requests per minute across 30+ microservices. Supported container and orchestration technologies, DevOps operating practices, alert creation, and alert tuning.',
|
||
|
||
'cv_job5_period' => 'August 2017 → March 2020',
|
||
'cv_job5_title' => 'Cross Functional Manager - Softtek | Electronic Arts',
|
||
'cv_job5_desc' => 'Incident, Problem, Asset Management, and Automation (ITIL-based) process implementation, Continuous Improvement Assessments.',
|
||
|
||
'cv_job6_period' => 'September 2015 → August 2017',
|
||
'cv_job6_title' => 'Linux Support Engineer / Tech Lead - Softtek | General Electric',
|
||
'cv_job6_desc' => 'Incident, Change management, and monitoring for internal applications. Promoted to tech lead after one year in support position.',
|
||
|
||
'cv_job7_period' => 'February 2013 → August 2015',
|
||
'cv_job7_title' => 'Customer Support Agent – Teleperformance | Comcast',
|
||
'cv_job7_desc' => 'Provided customer support services taking calls from the US Southwest area to troubleshoot cable, phone, and internet services.',
|
||
|
||
'blog_kicker' => 'Homelab field notes',
|
||
'blog_title' => 'I accidentally built a tiny CI/CD platform',
|
||
'blog_subtitle' => 'A case-study style walkthrough of how a Debian control plane, Pimox app workers, external Gitea, local registry, Kyverno policy, Argo CD, monitoring, and static demo shelf became a repeatable Kubernetes delivery path.',
|
||
'case_studies_kicker' => 'Portfolio case studies',
|
||
'case_studies_title' => 'Production-shaped evidence',
|
||
'case_studies_intro' => 'These are the three proof points a hiring manager should see first: platform ownership, production reliability at scale, and the reserved MLOps path for model-serving work.',
|
||
'case_platform_label' => 'Case 01',
|
||
'case_platform_title' => 'Self-hosted Kubernetes delivery platform',
|
||
'case_platform_desc' => 'Git push, validation, image build, registry, GitOps sync, policy guardrails, monitoring, retained storage, and VM worker provisioning in one small but operationally honest platform.',
|
||
'case_platform_link' => 'View architecture',
|
||
'case_sre_label' => 'Case 02',
|
||
'case_sre_title' => 'Enterprise SRE and incident automation',
|
||
'case_sre_desc' => 'Oracle and prior enterprise roles show the production side: 20,000+ developer users, 10,000+ external customers, Linux troubleshooting, automation, runbooks, on-call improvement, and high-scale incident response.',
|
||
'case_sre_link' => 'View CV evidence',
|
||
'case_mlops_label' => 'Case 03',
|
||
'case_mlops_title' => 'MLOps deployment platform placeholder',
|
||
'case_mlops_desc' => 'Reserved for the next serious demo: FastAPI inference, Kubernetes manifests, rollout strategy, model metrics, drift signals, and rollback behavior.',
|
||
'case_mlops_link' => 'Open placeholder',
|
||
'blog_speaker_question' => 'Future me, judging',
|
||
'blog_speaker_answer' => 'Me, holding coffee',
|
||
'blog_q1' => 'Be honest: why build all this instead of just running a couple containers like a normal person?',
|
||
'blog_a1' => 'Because apparently I looked at "host a website" and thought, "what if this had a control plane, GitOps, retained storage, an image registry, and several new ways to embarrass myself?" The real goal was practice: provision the infra, keep config in Git, deploy with automation, break it, fix it, and make sure I could rebuild it without relying on shell history and vibes.',
|
||
'blog_q2' => 'Why kubeadm? Were managed clusters too emotionally stable?',
|
||
'blog_a2' => 'Pretty much. kubeadm keeps the cluster close to the metal, which is a polite way of saying I get to see every sharp edge. The Debian node runs the control plane, the Raspberry Pi joins as an arm64 worker, and Pimox on an Orange Pi 5 Plus now gives me a repeatable way to add Debian 13 arm64 VM workers. Suddenly networking, storage, container runtimes, certs, and node recovery are not mysterious cloud magic. They are my problem.',
|
||
'blog_q3' => 'So where is the CI/CD part hiding?',
|
||
'blog_a3' => 'It is small, but it is real. OpenTofu brings up the cluster, platform, apps, and edge layers. Argo CD watches Git from the app workers, Kyverno keeps policy pressure on the workloads, Docker Buildx builds linux/arm64 images, and the local registry feeds the cluster. No enterprise dashboard fireworks, just a clean loop: Git changed, image built, cluster updated, nobody had to kubectl-edit anything at 2 AM.',
|
||
'blog_q4' => 'Why run your own registry and Gitea? Was the simple option unavailable?',
|
||
'blog_a4' => 'The simple option was very available, which is why I heroically ignored it. The registry means experiments do not need to go to a public image repo, and external Gitea gives the lab its own Git service without making Kubernetes responsible for its own source of truth. Together they make the setup feel less like "some containers under the stairs" and more like a tiny platform with opinions, responsibilities, and occasionally dramatic storage needs.',
|
||
'blog_q5' => 'What actually hurt the most?',
|
||
'blog_a5' => 'Storage. Always storage. Kubernetes, Docker, retained volumes, and build caches can fill a small root disk with the quiet confidence of a bad decision. Moving OpenEBS local volumes and Docker data to the external SSD turned the lab from "why is everything on fire?" into "okay, this is usable now." Growth, allegedly.',
|
||
'blog_q6' => 'So the platform controllers finally moved off the control plane?',
|
||
'blog_a6' => 'Yes. Argo CD and Kyverno now target the homelab.dev/node-role=app workers, including Kyverno hook jobs, so the Debian node can stay focused on control-plane duties. That one change made the lab feel less like everything was balanced on the first machine that happened to boot.',
|
||
'blog_q7' => 'Can the current cluster actually handle all that, or are we about to smoke the Pi?',
|
||
'blog_a7' => 'The Pi survives because the demos are intentionally local-first and now ship as a separate static artifact. The website pod stays a portfolio shell, the demos-static pod serves static bundles, and the user browser does the expensive work. If I later ship real ONNX object detection, Transformers.js, or full video transcoding models, those must lazy-load in the browser or move to a beefier node. The Raspberry Pi is brave, but it is not a GPU wearing a tiny hat.',
|
||
'blog_q8' => 'So the lab can now build its own worker nodes?',
|
||
'blog_a8' => 'Yes, and now with fewer crossed fingers. Debian runs a provisioning layer with dnsmasq, nginx, PXE boot files, GRUB, and a Debian 13 arm64 preseed. OpenTofu talks to Pimox through qm, creates VM 9000 on local storage, boots it from the network, installs the OS, runs golden-node prep, disables swap, verifies cgroups, installs containerd and kubeadm tooling, then seals it as a template. Worker clones are idempotent by VMID and now land on nvme_thin_pool, so local storage stays reserved for the template.',
|
||
'blog_q9' => 'And OpenWrt is joining the story too?',
|
||
'blog_a9' => 'Only as a simple firewall, not as a networking science project. The pipeline can create an opt-in OpenWrt ARM SystemReady VM, attach vmbr0 as WAN and vmbr1 as LAN, and configure the LAN side without rewriting Orange Pi host networking. DHCP stays optional, and VLANs wait until there is a managed switch and a local test window.',
|
||
'blog_q10' => 'What changed on the observability and scheduling side?',
|
||
'blog_a10' => 'Monitoring moved from "someday" to "running," and scheduling moved from "whatever fits" to explicit worker placement. Prometheus Stack, Grafana, Loki, Promtail, node-exporter, and kube-state-metrics give the lab useful signals; the next useful step is choosing the few alerts that would actually wake me up for the right reasons.',
|
||
'blog_stack_title' => 'Technologies and why they are here',
|
||
'blog_stack_1' => 'Debian Linux is the steady adult in the room: control plane host, deployment workstation, PXE/preseed server, and the place where OpenTofu, Docker, kubeadm, and the scripts do their thing.',
|
||
'blog_stack_2' => 'Raspberry Pi keeps the external Gitea service close to the lab, while Pimox on the Orange Pi 5 Plus provides the app-worker pool. The Debian template stays on local storage and Kubernetes worker clones go to nvme_thin_pool.',
|
||
'blog_stack_3' => 'OpenTofu makes the cluster, platform, apps, edge, and provisioning layers repeatable, because "I swear I remember the command" is not a disaster recovery strategy.',
|
||
'blog_stack_4' => 'Calico handles pod networking, and OpenEBS hostpath storage keeps the important data around after rebuilds, because deleting everything by accident is only funny once.',
|
||
'blog_stack_5' => 'Argo CD is the GitOps referee and now runs on app workers: manifests live in Git, the cluster follows along, and manual drift gets side-eyed back into place.',
|
||
'blog_stack_6' => 'The OCI edge host runs nginx, HAProxy, Varnish, and Squid so TLS, routing, and caching stay outside the home network while Tailscale sneaks the traffic back to the worker node.',
|
||
'blog_stack_7' => 'The shared theme toggle is plain CSS and JavaScript: dark mode uses an old-console green-on-black treatment, while light mode switches to black cursive on ivory across the website and demo catalog.',
|
||
'blog_stack_8' => 'The first demo keeps files in the browser. Image crunching uses native Canvas APIs today, while the fast serious path for video conversion is Rust compiled to WebAssembly with a TypeScript UI.',
|
||
'blog_stack_9' => 'The newer demos cover network jitter graphs, local JSON/JWT/log tools, an architecture simulator, an offline traveler converter, a redactor prototype, sentiment analysis, model-drift simulation, and the reserved MLOps platform page.',
|
||
'blog_stack_10' => 'The serious MLOps page is intentionally only a placeholder for now. The target design is a production-shaped inference demo with FastAPI, Kubernetes deployment, metrics, drift signals, canary or blue-green rollout, and rollback notes.',
|
||
'blog_stack_11' => 'The demo code now builds into its own demos-static image and Argo CD app, exposed at /demo-apps/. The PHP website only owns the catalog link, which is much less cursed.',
|
||
'blog_stack_12' => 'The Pimox worker pipeline uses qm over SSH to create an OVMF/virtio-scsi Debian 13 arm64 VM, wait for qemu-guest-agent, seal it, and convert VM 9000 into a reusable template on local storage.',
|
||
'blog_stack_13' => 'The golden image bakes in Kubernetes prerequisites: swap disabled, cgroup boot options checked, kernel modules loaded, containerd configured for systemd cgroups, kubeadm/kubelet/kubectl installed, and qemu-guest-agent enabled.',
|
||
'blog_stack_14' => 'Worker clone automation is count-based and idempotent: LAB_PIMOX_WORKER_COUNT=1 means ensure VM 9010 exists, not create a fresh worker on every run. New workers are refused if the target storage is local.',
|
||
'blog_stack_15' => 'OpenWrt is handled separately from the Debian golden-node template. The lab downloads the upstream ARM SystemReady EFI image, imports it as VM 9050 on nvme_thin_pool, and keeps it disabled unless LAB_OPENWRT_VM=true is set.',
|
||
'blog_stack_16' => 'The monitoring layer now includes Prometheus Stack, Grafana, Loki, Promtail, node-exporter, and kube-state-metrics, with placement guardrails so platform add-ons stop defaulting to the control plane.',
|
||
'blog_arch_kicker' => 'Architecture map',
|
||
'blog_arch_title' => 'The homelab, end to end',
|
||
'blog_arch_intro' => 'The current delivery path starts with a push to Gitea, runs local validation, builds arm64 images, syncs the validated commit into the GitOps mirror, and lets Argo CD reconcile from the app workers. The infrastructure path stays manual through lab.sh, including the PXE/Pimox template builder, NVMe-backed worker clones, Kyverno policy placement, and the opt-in OpenWrt firewall VM, while the OCI edge routes public traffic back through the private path.',
|
||
'blog_arch_caption' => 'The diagram is intentionally operational: it shows the app delivery loop, image flow, provisioning path, worker-placement boundary, monitoring layer, OpenWrt firewall option, and public traffic path without hiding the practical bits that make a small lab behave like a platform.',
|
||
'blog_arch_fun_link' => 'Open the Christmas-tree version',
|
||
'blog_activity_kicker' => 'Recent activity log',
|
||
'blog_activity_title' => 'What changed since the first build',
|
||
'blog_activity_intro' => 'The lab moved from a working Kubernetes experiment into a more complete self-hosted delivery system. The latest work focused on trust, repeatability, VM-based expansion, controller placement, and making deploys match the exact commit that passed validation.',
|
||
'blog_activity_1' => 'Moved Gitea out of Kubernetes and onto the Raspberry Pi as the local Git service, while keeping the public /git/ route through the edge stack.',
|
||
'blog_activity_2' => 'Installed and validated a Debian-hosted Gitea Actions runner so pushes to main can build, scan, and deploy without depending on a laptop session.',
|
||
'blog_activity_3' => 'Added a custom checkout flow for the /git/ subpath and kept a persistent Debian checkout for the deployment scripts.',
|
||
'blog_activity_4' => 'Added Gitleaks secret scanning and Trivy scanning for the app and infrastructure tree.',
|
||
'blog_activity_5' => 'Changed deployment so the validated commit is pushed into the local GitOps mirror before lab.sh runs, preventing Argo CD from reconciling an older tree.',
|
||
'blog_activity_6' => 'Hardened the website, demos-static, and registry workloads with non-root containers, read-only root filesystems, resource limits, and explicit writable volumes.',
|
||
'blog_activity_7' => 'Split the demos into a dedicated demos-static image and Argo CD application so the PHP website stays small and boring.',
|
||
'blog_activity_8' => 'Changed Gitea backups to dump from the Raspberry Pi Docker container and store archives on the Debian host.',
|
||
'blog_activity_9' => 'Validated the full main-branch deployment path: fetch main, apply OpenTofu layers, build and push arm64 images, refresh Argo CD, and confirm the runner completes successfully.',
|
||
'blog_activity_10' => 'Built the Debian 13 arm64 Pimox template end to end with PXE, preseed, qemu-guest-agent discovery, cgroup validation, swap disabled, and a final seal step.',
|
||
'blog_activity_11' => 'Added NVMe-backed Pimox worker clone automation so VM 9000 stays on local storage while worker nodes are created on nvme_thin_pool.',
|
||
'blog_activity_12' => 'Added an opt-in OpenWrt VM path for a simple firewall between vmbr0 and vmbr1, with guardrails that avoid Orange Pi host networking changes.',
|
||
'blog_activity_13' => 'Installed the monitoring stack and moved platform add-ons such as Argo CD, Kyverno, and prometheus-stack work toward app-worker placement instead of treating the control plane as spare capacity.',
|
||
'blog_todo_kicker' => 'Improvement backlog',
|
||
'blog_todo_title' => 'Todo list for the next homelab pass',
|
||
'blog_todo_intro' => 'These are improvement proposals, not chores for the sake of chores. Each item either reduces rebuild risk, tightens supply-chain hygiene, or makes the platform easier to operate when something fails.',
|
||
'blog_todo_1' => 'Move Gitea data from the Raspberry Pi SD card to SSD-backed storage.',
|
||
'blog_todo_2' => 'Keep the Debian bare GitOps mirror as the cluster source and add object-storage backups when OCI storage is ready.',
|
||
'blog_todo_3' => 'Add a real OpenTofu remote state backend with backup, locking, and a documented recovery path.',
|
||
'blog_todo_4' => 'Replace the remaining mutable latest image references with immutable tags or digest pins for demo workloads; the website image now uses a content-hash tag.',
|
||
'blog_todo_5' => 'Generate SBOMs and sign images so the local registry can prove what it is serving.',
|
||
'blog_todo_6' => 'Add Renovate or Dependabot-style dependency updates for base images, Helm charts, and GitHub/Gitea Actions.',
|
||
'blog_todo_7' => 'Expand Kyverno baseline policy coverage: non-root, read-only roots, resource requests, allowed registries, and documented exceptions for platform components.',
|
||
'blog_todo_8' => 'Turn the installed observability stack into useful operations views: a few high-signal dashboards, alerts for node health, storage pressure, certificate expiry, and failed app syncs.',
|
||
'blog_todo_9' => 'Schedule backup restore drills for external Gitea and OpenEBS volumes, then write the exact restore runbook.',
|
||
'blog_todo_10' => 'Tighten TLS, SSH, and token rotation around the OCI edge, Gitea, registry, and runner credentials.',
|
||
'blog_todo_11' => 'Document the new storage split: local for the Pimox template, nvme_thin_pool for VM workers, OpenEBS for Kubernetes app data, and backup targets for anything that must survive a rebuild.',
|
||
'blog_todo_12' => 'Move sensitive app configuration into Sealed Secrets, External Secrets, or another explicit secret-management path.',
|
||
'blog_todo_13' => 'After the new disk has breathing room, clone the first Pimox worker from VM 9000, join it with kubeadm, and verify labels, taints, CNI, storage, and workload scheduling.',
|
||
'blog_todo_14' => 'Test the OpenWrt VM in a maintenance window before making it a gateway: confirm WAN, LAN, rollback access, DHCP settings, and that Pimox remains reachable.',
|
||
'blog_todo_15' => 'Buy or configure a managed switch before VLAN work. Until then, keep OpenWrt as a simple two-interface firewall and avoid risky remote bridge rewrites.',
|
||
'blog_ideas_kicker' => 'Visitor ideas',
|
||
'blog_ideas_title' => 'What would you improve next?',
|
||
'blog_ideas_intro' => 'Send a practical idea for the homelab backlog. Submissions are stored as plain text, limited in size, and rendered escaped.',
|
||
'blog_ideas_name_label' => 'Name, optional',
|
||
'blog_ideas_text_label' => 'Improvement idea',
|
||
'blog_ideas_submit' => 'Send idea',
|
||
'blog_ideas_recent_title' => 'Recent visitor ideas',
|
||
'blog_idea_status_thanks' => 'Thanks. Your idea was added to the backlog suggestions.',
|
||
'blog_idea_status_invalid' => 'That idea was too short or too large. Please send a concise plain-text suggestion.',
|
||
'blog_idea_status_slow' => 'Please wait a moment before sending another idea.',
|
||
'blog_idea_status_error' => 'The idea could not be saved right now. Please try again later.',
|
||
'tree_kicker' => 'Fun architecture mode',
|
||
'tree_title' => 'The Homelab Christmas Tree',
|
||
'tree_subtitle' => 'Same platform, less serious outfit: every part of the homelab becomes a tree part, from the public DNS star down to the storage roots and backup gifts.',
|
||
'tree_back_to_blog' => 'Back to the professional diagram',
|
||
'tree_key_kicker' => 'Tree legend',
|
||
'tree_key_title' => 'What each festive part means',
|
||
'tree_key_intro' => 'The joke still maps to the real architecture: each visual part has one operational job in the homelab.',
|
||
|
||
'demos_kicker' => 'Small tools, real browser work',
|
||
'demos_title' => 'Demo Apps',
|
||
'demos_subtitle' => 'A growing shelf of small apps shipped as separate static demo artifacts. The website stays light; each demo gets its own page under /demo-apps/, including a reserved MLOps platform placeholder.',
|
||
'demo_cruncher_label' => 'Demo 01',
|
||
'demo_cruncher_title' => 'The Client-Side Media Cruncher (Wasm + TS)',
|
||
'demo_cruncher_desc' => 'Drop in a large image and convert or compress it locally. The browser does the work, the server sees nothing, and your file does not take a suspicious vacation through a random converter site.',
|
||
'demo_network_label' => 'Demo 02',
|
||
'demo_network_title' => 'How Is My Internet, Really?',
|
||
'demo_network_desc' => 'A live Canvas dashboard that samples latency to this site, estimates jitter, and visualizes stability instead of pretending one speed-test number tells the whole story.',
|
||
'demo_toolbelt_label' => 'Demo 03',
|
||
'demo_toolbelt_title' => 'Local Log and JSON Toolbelt',
|
||
'demo_toolbelt_desc' => 'Prettify JSON, decode JWT payloads, parse URLs, and grep text logs locally without pasting private data into mystery websites.',
|
||
'demo_arch_label' => 'Demo 04',
|
||
'demo_arch_title' => 'Interactive System Architecture Simulator',
|
||
'demo_arch_desc' => 'A tiny traffic playground where users, load balancers, web nodes, and a database show how systems scale, fail, and recover.',
|
||
'demo_traveler_label' => 'Demo 05',
|
||
'demo_traveler_title' => 'Offline Traveler Converter',
|
||
'demo_traveler_desc' => 'A PWA-style timezone, currency, and data-unit converter for flights, remote teams, and those meetings that somehow happen tomorrow and yesterday.',
|
||
'demo_redactor_label' => 'Demo 06',
|
||
'demo_redactor_title' => 'Privacy-First Object Redactor',
|
||
'demo_redactor_desc' => 'Drop an image, blur sensitive regions locally, and download the redacted result. No upload, no backend, no awkward explanation to security.',
|
||
'demo_sentiment_label' => 'Demo 07',
|
||
'demo_sentiment_title' => 'Local Sentiment and Text Analytics',
|
||
'demo_sentiment_desc' => 'Paste reviews, support notes, or essays and get instant local sentiment, keywords, and a tiny summary without calling an API.',
|
||
'demo_drift_label' => 'Demo 08',
|
||
'demo_drift_title' => 'Model Drift and Performance Simulator',
|
||
'demo_drift_desc' => 'A visual MLOps playground where traffic spikes and corrupted inputs drag model accuracy down until retraining brings it back.',
|
||
'demo_mlops_label' => 'Demo 09',
|
||
'demo_mlops_title' => 'MLOps Deployment Platform',
|
||
'demo_mlops_desc' => 'Placeholder for the serious MLOps showcase: inference service, Kubernetes rollout, metrics, drift signals, and rollback workflow.',
|
||
];
|