📚

Learning Log

📱 Starting the Mobile App Development Journey

🎯 The Vision

Want to transform hellooowwworld.com into installable mobile apps
Goal: Publish to both Google Play Store and Apple App Store
Budget constraint: $100-$250 (realistic and achievable!)
Learning all three approaches: Web Wrapper, Cross-Platform, and Native

💰 Budget Reality Check

Google Play Developer Account: $25 one-time fee
Apple Developer Account: $99/year subscription
Total required: $124 (leaves $0-126 for development)
Great news: All development tools are completely FREE
Android Studio, Xcode, npm, Node.js, Capacitor = $0 cost

🔍 Three Approaches Compared

Web App Wrapper (Capacitor): Your website packaged as an app (2-5 hours, easiest)
Cross-Platform (React Native/Flutter): Write once, deploy both platforms (4-8 weeks, medium)
Native Development (Swift/Kotlin): Separate iOS and Android apps (8-16 weeks, hardest)
Web wrapper = fastest path to launch with $124 budget
Cross-platform = best balance of speed, cost, and quality
Native = maximum performance but highest cost and time investment

🚀 Phase 1: Web App Wrapper Strategy

Decided to start with Option 1: Web App Wrapper (Capacitor)
This approach wraps existing website in native app container
Can launch in 1-2 days vs weeks/months for other approaches
Learn app store submission process while keeping development simple
Foundation for later upgrading to React Native or native apps

⚙️ Development Environment Setup

Step 1 Complete: Installed Node.js v24.14.0 on Windows
Step 2 Complete: Verified npm v11.9.0 installation
Next Steps: Set up Google Play and Apple Developer accounts
Then install Android Studio (for Android development)
Then install Xcode (for iOS development - Mac only)
Install Capacitor framework to wrap the website

📚 Key Learnings About Mobile Apps

Capacitor is made by the same team that created Ionic Framework
Web apps can be 80-90% as performant as native apps with Capacitor
Service workers enable offline functionality for web-wrapped apps
App store approval process is similar for both Android and iOS (1-3 days)
Package naming is critical: com.yourname.appname (reverse domain format)
Digital signing keys are needed for Google Play (managed by Capacitor)

🎓 What This Means for Your Journey

You can have apps on BOTH app stores for only $124!
The website you already built becomes the app - no rewrites needed
This proves concept before investing time in native development
Users can access hellooowwworld.com as an installable app
Learning curve is minimal since you already know HTML/CSS/JavaScript

📅 Timeline Projection

Today/Tomorrow: Set up accounts, install tools
Day 2-3: Configure Capacitor and build wrapper
Day 3-4: Create app icons and splash screens
Day 4-5: Submit to Google Play Store
Day 5-6: Submit to Apple App Store
Day 7-10: Wait for approvals (usually 1-3 days each)
Total: Fully published in ~2 weeks!

🎯 Current Status & Next Steps

✅ Node.js and npm installed and verified
⏳ Waiting to set up Google Play Developer Account ($25)
⏳ Waiting to set up Apple Developer Account ($99)
⏳ Install Android Studio (free, ~2 hours setup)
⏳ Install Xcode (free but Mac only, ~3 hours setup)
⏳ Create Capacitor project and integrate website
⏳ Build and test on emulators
⏳ Create app icons and splash screens
⏳ Submit to both app stores

💡 Key Insight

Professional mobile app development seems intimidating, but breaking it down into steps makes it manageable
You don't need a $100k budget or a team - solo developers ship apps all the time
Your existing website is already done - you're just packaging it, not rebuilding
Understanding the "why" (why Capacitor, why accounts, why signing keys) helps with learning
This journey shows that learning to code opens doors you didn't know existed

⚡ Efficient Workflow: Batch Commits & Site Updates

🎯 The Challenge

Made many small changes and pushed after each one = tons of deploys
Hit Netlify bandwidth limits from excessive rebuilds
Realized: need to batch changes for efficiency

💡 The Solution: Batch Commits

Make edits locally and commit WITHOUT pushing
Batch multiple commits together
Push once = ONE deploy instead of multiple
Result: Much faster, fewer builds, less bandwidth waste

🔄 The Process We Used

Change 1: Remove celebratory message from homepage
Committed locally: `git commit -m "Remove celebratory message from homepage"`
Change 2: Remove footer text from homepage
Committed locally: `git commit -m "Remove footer text from homepage"`
Change 3: Add profile image to about page
Created images/ folder for asset organization
Added image with CSS styling for nice presentation
Committed locally: `git commit -m "Add profile image to about page"`
Final Step: Pushed all 3 commits at once: `git push origin main`

📁 Best Practice: Asset Organization

Created `images/` folder at project root
All images stored in one place for easy management
HTML references images: ``
Scalable structure - can add `css/`, `js/` folders later
Each site version has its own images/ copy

🎨 Profile Image Implementation

Added CSS class `.profile-image` with responsive sizing
Image width: 100% with max-width: 300px (responsive)
Rounded corners (border-radius: 15px) for modern look
Box shadow for depth and visual interest
Positioned at top of about page above title

💾 Git Workflow Mastery

Understanding the difference: commit vs push
Commits are local snapshots (safe, can make many)
Push sends commits to GitHub (triggers Netlify deploy)
Batch committing = batch pushing = single deploy
This prevents Netlify bandwidth overages

🚀 Deployment Impact

Old workflow: 1 edit → 1 commit → 1 push → 1 deploy (wasteful!)
New workflow: 3 edits → 3 commits → 1 push → 1 deploy (efficient!)
Reduced rebuild time by batching changes together
Saved bandwidth and deployment credits on Netlify
Upgraded Netlify plan to Personal ($9.99/month) for peace of mind

🎓 Key Takeaways

Professional developers batch changes, not push after every edit
Understanding deployment systems prevents cost overruns
Small optimizations add up (fewer builds = faster, cheaper)
Git is powerful: local commits are safe and don't affect live site
File organization (images/, css/, js/) matters from day one
Responsive images important for user experience across devices

✨ What's Different Now

Homepage is cleaner (removed celebratory messages and footer)
About page has profile image at the top for personalization
Better workflow going forward = more sustainable development
Understanding the "why" behind each change

🎨 Building a Site Versioning System

💡 The Idea

Wanted to preserve snapshots of the site as it evolved over time
Goal: Let visitors see what the site looked like on specific dates
Use case: Share your learning journey with others by showing progress
Hidden from main navigation - only accessible via Learning Log

🔧 Implementation Approach

Chose static folder approach over Git tags (simpler to manage now)
Created v0.1-feb-17/ folder with complete site snapshot
Each version is self-contained with all pages: index, about, projects, learning
Internal links within each version stay within that folder
Added version badges (📦 v0.1 • Feb 17, 2026) to each page

🎯 What Got Built

Created v0.1-feb-17/index.html - Homepage snapshot with version badge
Created v0.1-feb-17/about.html - About page snapshot
Created v0.1-feb-17/projects.html - Projects page snapshot
Created v0.1-feb-17/learning.html - Complete learning log snapshot with link back to current
Updated current learning.html with archive link to v0.1

🎓 Learning About Versioning

Version numbers follow semantic versioning: v0.1, v0.2, etc.
Snapshots preserve the exact state of the site at a point in time
Self-contained versions prevent confusion - visitors don't accidentally blend old and new content
Version badges help visitors understand they're looking at an archived version
Static folders are easy to implement and maintain

💻 Technical Details

URL structure: /v0.1-feb-17/index.html (mirrors main site structure)
Each version can be navigated independently
Easy to add new versions in the future: v0.2-march-01/, v0.3-april-15/, etc.
Can pivot to Git tags later without rewriting current implementation
Committed all files to GitHub for backup and documentation

✨ Future Possibilities

Could add a "timeline" page showing all versions with screenshots
Could compare two versions side-by-side to see changes
Could add Git tags to document versions in repository history
As you learn more, you'll have visual proof of your progress!

🎉 Site Improvements Today

Added collapsible learning log entries (click dates to expand/collapse)
Reversed entry order so newest entries appear first
Created versioned snapshots for historical browsing
Added smooth animations for better UX
Each version has consistent styling with version badges

🧠 Big Picture Insights

Professional developers track versions of their sites/apps constantly
Versioning systems help you see your growth over time
Organization matters - clear folder structure makes everything easier
Think about user experience - version badges and clear navigation help people understand what they're looking at
Keep it simple at first, upgrade complexity later as needed

🛠️ Solving the Claude Code Git Integration Issue

⚙️ The Problem

Claude Code requires Git to work locally
After downloading Git for Windows, Claude Code still showed an error
Error message: "Git is required for local sessions"

🔍 Debugging & Troubleshooting

First instinct: restart the application - this often solves installation issues
Used Git Bash terminal to locate the Git installation path
Ran `which git` command to find the executable location
Made a typo initially (`which get` instead of `which git`) - caught and corrected it
Learned that command precision matters - one letter changes everything!

💡 Key Learning: Path Conversion

Git Bash uses Unix-style paths: `/mingw64/bin/git`
Windows system variables need Windows-style paths: `C:\Program Files\Git\bin\bash.exe`
Understanding the difference between Unix and Windows path formats is crucial
Tools like Git Bash create a Unix environment on Windows, but system variables stay Windows-native

🎯 The Solution

Claude Code specifically needs the path to `bash.exe`, not `git.exe`
Environment variable: `CLAUDE_CODE_GIT_BASH_PATH` points to `C:\Program Files\Git\bin\bash.exe`
After setting the environment variable, Claude Code needs to be fully restarted
The environment variable persists after restart, allowing the application to find Git

🧠 Broader Lessons

Installation issues often have simple fixes - restart is always worth trying first
Environment variables are how applications find dependencies on your system
Different operating systems (Windows vs Unix/Linux/Mac) have different conventions
Error messages guide you toward solutions - they tell you what's missing and what to fix
Getting stuck is normal - methodical troubleshooting always wins
Small typos (get vs git) can completely change outcomes - attention to detail matters

🔄 Automating Website Deployment with Git

Created a new "Projects" page placeholder for future project showcases
Set up local Git repository to automate deployment workflow
Connected local folder to existing GitHub repository using `git remote add origin`
Staged all files with `git add .` and committed with descriptive messages
Configured Git identity (email and name) for commit attribution
Pushed changes to GitHub with `git push -u origin master`

🚀 The Complete Deployment Pipeline

Local changes (editing HTML files) → Save files on computer
Git commits (staging and committing changes) → Creates snapshots of your work
GitHub push (uploading to GitHub) → Backs up code and triggers Netlify
Netlify auto-deploy (automatic website update) → Live changes appear instantly
This entire workflow is now automated - no manual file uploads needed!
Understanding this pipeline is essential for professional web development

💡 Version Control & Collaboration Insights

Git is a "version control system" - it tracks every change you make
Commit messages should be clear and descriptive - they document WHY you made changes
GitHub serves as both backup and collaboration hub for development teams
Webhooks (like Netlify's integration) connect services together automatically
This workflow enables multiple developers to work on the same project safely
Learned the difference between local changes, commits, and pushes

🎯 Troubleshooting GitHub Authentication

Created a new "Projects" page with a rocket emoji 🚀 and placeholder text
Added Projects button to the navigation on the home page
Tried to push changes but hit authentication errors with HTTPS
Jarad installed GitHub CLI (and verified it was actually installed!)
Ran `gh auth login` and successfully authenticated with GitHub

🔍 Debugging a Branch Mismatch Issue

Files were committed locally but not appearing on GitHub
Claude discovered the real issue: GitHub repo uses "main" but we were pushing to "master"
GitHub CLI helped identify the default branch mismatch
Forced pushed from local "master" branch to remote "main" branch
Verified all files were finally on GitHub using the GitHub API

🏆 Key Learnings from Today

GitHub has a concept of "default branches" - older repos use "master", newer ones use "main"
Branch mismatches can silently fail - files don't appear where you expect them
GitHub CLI is a powerful tool that can diagnose repo issues and authenticate securely
Force push is a dangerous tool but sometimes necessary when dealing with branch conflicts
Persistence pays off - troubleshooting took time but we solved it!
Reading error messages carefully is the first step to fixing problems
Sometimes the solution isn't in the code - it's in the configuration

✨ What This Means

Your website now has a fully automated workflow: edit → commit → push → live!
The Projects page is live and ready for you to add real projects later
You now understand Git, GitHub, authentication, and deployment better than most beginners
YOU did the hard part - staying curious and troubleshooting when things didn't work

🎓 What I Learned Today

💻 HTML, CSS & JavaScript

Learned how HTML structures content (headings, buttons, links)
Understood CSS styling (colors, fonts, animations, gradients) - Claude built it, I saw how it works
Watched JavaScript add interactivity (button clicks, dynamic emojis)
Studied working animations using @keyframes by reading the code

🌐 Domain Registration & DNS

Independently registered hellooowwworld.com through Squarespace
Followed Claude's guidance to configure nameservers
Learned about DNS propagation through troubleshooting together
Successfully connected custom domain to live website

🚀 Netlify Deployment

Dragged and dropped files to deploy via Netlify (with much trial and error!)
Debugged folder structure issues - Claude helped identify the problem
Configured custom domain settings with step-by-step guidance
Set up continuous deployment from GitHub together

🔧 GitHub Version Control

Created my first GitHub repository
Uploaded files and learned what commits are
Connected GitHub to Netlify - Claude walked me through each step
Now understand how auto-deploy works in professional workflows

🔗 Connecting Services Together

Orchestrated Squarespace + Netlify + GitHub (with heavy guidance!)
Learned how services communicate - Claude explained webhooks and APIs
Built a real professional development pipeline by following instructions
Understood the "why" behind each connection through collaboration

🐛 Debugging Like a Pro

Hit 404 errors repeatedly - Claude helped diagnose file structure issues
Figured out .html vs .txt file format problems together
Worked through DNS configuration and deployment bugs as a team
Learned that getting stuck and problem-solving IS the learning process

💡 Tip: Click on any date to expand or collapse that day's learnings. This page will grow as you continue learning!

← Back to Home