✨ Polishing the Experience: Why Performance Matters
Posted on September 9, 2025
Performance isn’t just about speed it’s about trust. By refining animations and layout behaviour, I transformed my site from visually chaotic to confidently smooth. This post explores how small tweaks led to a big mindset shift: from building pages to crafting experiences.
After weeks of building, debugging, and designing, I finally turned my attention to something less visible but deeply impactful: performance. Not just how fast my site loads, but how stable it feels. How it behaves when someone scrolls, clicks, or simply lands on the homepage.
The Invisible Metric That Shapes Trust I dove into Chrome DevTools and Cloudflare analytics, curious about a metric called Cumulative Layout Shift (CLS). It tracks how much a page jumps around while loading and even tiny shifts can make a site feel chaotic or unpolished. My initial CLS score was high. Something was moving unexpectedly. So I investigated.
The Culprit: Animated Icons No ads. No banners. No homepage images. But I did have animated icons playful flourishes that added personality. I reviewed every animation: • Reserved space for each element before it loaded • Switched from layout-affecting properties to transform • Added will-change hints for smoother rendering Cleaned up redundant keyframes and transitions
The Results: Stability You Can Feel After refining the CSS, my CLS score dropped to 0.01 - 0.04 across all pages. Cloudflare now reports 100% of my site in the “Good” range no layout shifts, no visual hiccups. Just clean, confident rendering.
The Mindset Shift It’s easy to overlook performance when you’re focused on features and design. But polish isn’t just about how things look it’s about how they feel. When a site feels stable, responsive, and intentional, people notice. Even if they don’t know why. This wasn’t just a technical fix. It was a shift in how I think about building. I’m not just creating pages anymore I’m crafting experiences.
1 views
🧩 Syncing My Django Project from cPanel to GitHub (and Back to PyCharm)
Posted on September 4, 2025
Syncing my Django project from cPanel to GitHub and back into PyCharm required reversing the usual deployment flow. After configuring Git identity and switching to a Personal Access Token for GitHub authentication, I successfully pushed the updated code. On my local machine, I resolved conflicts by stashing changes before pulling the latest version into PyCharm. Now everything is synced across server, cloud, and IDE and I’m finally ready for the next sprint.
The Problem I had a Django project running live on my cPanel-hosted server. The files on the server were up to date, but my GitHub repo was stale, and my PyCharm project was even further behind. I needed to reverse the usual flow, not push from GitHub to the server, but pull the live site into GitHub, then sync it locally. Sounds simple? It wasn’t. But I got there.
Step-by-Step Breakdown
1. Identifying the Git Repo and Live Site • My Git repo • My live Django site I couldn’t deploy directly from GitHub because cPanel wouldn’t allow it the folder already had files. So I needed to copy the live site into the Git repo.
2. Avoiding Recursive Copy Errors I accidentally tried to copy My Site into itself. Classic mistake. Safely synced the live site into the Git repo without dragging .git internals into chaos.
3. Authentication with GitHub GitHub rejected my password. Why? Because it doesn’t accept passwords anymore. I generated a Personal Access Token, used that instead, and boom push successful.
4. Pulling into PyCharm Back on my local machine, I opened the project in PyCharm and ran: git pull origin main Git stopped me I had local changes that conflicted. So I stashed them: git stash git pull origin main Then restored my working directory. Everything synced. Everything clean.
What I Learned • Git is powerful, but picky and that’s a good thing • cPanel deployment needs a .cpanel.yml file, but only works if the repo is clean • Always double-check your copy paths and wildcards • GitHub tokens are the new normal • PyCharm plays nicely once you resolve conflicts
Final Thoughts This wasn’t just a technical fix it was a full-circle sync across server, cloud, and local. I now have a clean GitHub repo, a deployable cPanel setup, and a PyCharm project that’s ready for the next sprint. And now? I’m calling it a night. Because even devs need sleep.
1 views
✅ Debugging & Deployment Part II: Django Finally Goes Live
Posted on September 3, 2025
After wrestling with static files, SSL errors, and admin lockouts, the Django app is finally live styled, secure, and dynamic. This post chronicles the final fixes, subdomain setup, and the moment everything clicked into place. Deployment wasn’t just a milestone it was a masterclass in full-stack resilience.
After days of debugging, configuring, and chasing down elusive errors, the site is finally live — styled, secure, and serving dynamic content. This post picks up where the last one left off: an internal server error 500, a misrouted SSL connection, and a Django app that was technically deployed but still inaccessible.
The Final Fix: Static Files & Permissions The breakthrough came when I realised that copying over the files from Render to cPanel made my settings file inaccurate. I during the troubleshooting I also noticed that collectstatic wasn’t picking up my custom CSS folder. I manually amended my settings file & created the missing directory inside staticfiles, uploaded the assets, and confirmed they were being served correctly. A little but important tweak to settings.py, a re-ran collectstatic, and restarted the app. Suddenly, the site was available and had styling no more MIME type errors, no more blank pages, no more internal server error!
Superuser Access & Admin Panel Next, I tackled the admin login. My original superuser credentials weren’t working, and Django wouldn’t let me recreate the account. So I dropped into the shell, reset the password manually, and finally regained access to the admin panel. With that, I created a second blog entry and wired up the homepage to display them dynamically.
Template Logic & Content Flow I refined the template to show the latest post in the main content area, while keeping the layout clean and focused. I removed the sidebar post list, simplified the navigation, and made sure everything felt intentional. (still working on the final layout…) The result? A journal-style blog that’s minimal, responsive, and fully powered by Django.
DNS & Subdomain Integration With the app stable, I linked it to a subdomain and styled a call-to-action button from the main site. DNS propagation completed without a hitch this time, and the blog is now seamlessly accessible from the homepage.
What Success Looks Like: • ✅ Django app deployed on shared hosting • ✅ Static files served via WhiteNoise • ✅ SSL routing resolved • ✅ Admin panel accessible • ✅ Dynamic content flowing
Final Takeaways: • Manual uploads can be the fastest fix when automation fails • WhiteNoise is powerful but unforgiving • Shared hosting is possible, but you’ll earn every inch • The real win isn’t just deployment it’s understanding every layer of the stack
2 views
🛠 Debugging, Deploying, and DNS: A Day in the Life of a Django Dev
Posted on September 2, 2025
A day of digital detective work: from ghosted stylesheets to rogue modules, I tackled deployment chaos and built a dynamic blog engine from scratch. The result? A site that’s a living journal of my growth as a developer.
Today was one of those days where development felt less like coding and more like detective work. From cryptic errors to invisible stylesheets, I wrestled with every layer of the stack and came out stronger.
The Mystery Module That Wouldn’t Die It started with a deployment error that refused to budge. I’d already renamed folders, updated references, and cleared every cache I could find but the system kept trying to load a module that no longer existed. The culprit? Legacy configuration settings buried deep in the environment. Once I tracked them down and cleaned them out, the build finally succeeded.
When CSS Goes Missing in Action Next up: the site loaded, but it looked like a ghost town. No styling, no layout just raw HTML. The CSS file was being served, but the browser refused to apply it. After some digging, I found the issue: a subtle formatting glitch in the template was breaking the stylesheet link. One fix later, and the site snapped back to life.
From Static to Dynamic: Building the Blog Engine With the foundation stable, I shifted focus to content. I built a Django model for blog posts, wired it into the admin panel, and created my first dynamic entry. Then I updated the homepage to pull posts directly from the database replacing static filler with a live feed of journal entries.
Subdomains & DNS: Connecting the Pieces To integrate the blog with my existing static site, I configured a subdomain and linked it from the “About Me” section using a styled call-to-action button. DNS propagation is still underway, but once complete, the blog will be seamlessly accessible from the main site.
What Today Taught Me This wasn’t just a day of bug fixes it was a masterclass in full-stack problem solving. I learned how to: - Trace issues across file structure, config, and templates - Build systems that evolve with content - Connect static and dynamic components into a cohesive experience The site is no longer just a showcase it’s becoming a living journal of my growth as a developer.
4 views
🚀 From Static to Dynamic: My Developer journey So Far
Posted on August 30, 2025
From a humble password generator to a full-fledged Django-powered blog, this post traces my evolution from static pages to dynamic web development. It’s not just about building websites it’s about building something that grows with me.
It started with a password generator. A simple desktop app built with Python and Tkinter my first taste of GUI design, logic, and user interaction. It wasn’t flashy, but it worked. And more importantly, I built it.
Then came the website. Static, elegant, and full of style. Crafted with HTML and CSS, sprinkled with JavaScript to add just enough sparkle. It was my digital canvas a place to showcase, experiment, and express. But static wasn’t enough.
I wanted more than pages. I wanted power. So I began learning Django a framework that felt intimidating at first, but quickly revealed its elegance. I set up my first project, created a blog app, built models, views, and templates. I debugged errors, ran migrations, and watched my first post appear on the homepage. I’m building a blog that will integrate with my existing site and eventually, replace it. The goal is to rebuild the entire website using Django, transforming it from a static showcase into a dynamic, database-driven experience.
It’s not just about code anymore.
It’s about growth. About learning how to build something that lives, breathes, and evolves. This is my journey from desktop to web, from static to dynamic. And it’s only just beginning.