🚀 Django Day 24 – Adding Images to the Project 🖼️ In yesterday’s video 🎥, I showed how the website looked like — it was coming together nicely, but there were no images on it yet 😅. So today, I decided to work on that and bring more life and visual appeal to the blog page 🌄. In Django, images are considered static files, which means they are implemented and attached in the same way CSS files are. For example, when linking a CSS file, I make use of the {% load static %} tag at the top of the HTML file, and then reference the file path like this: <link rel="stylesheet" href="{% static 'blog/styles.css' %}"> The same concept applies to images 🖼️ — for instance, if I want to add a blog banner or thumbnail, I can do something like this: <img src="{% static 'blog/images/blog-banner.jpg' %}" alt="Blog Banner"> This tells Django to look for the image in the static folder and display it properly on the page. Today’s focus was all about understanding how static files (especially images) are handled and how to properly link them within the templates. I also made sure the images directory was correctly structured inside the static folder and that my settings were configured to recognize them ✅. Now the blog page looks way more engaging and visually balanced 💻✨ There’s a video below 🎬 showing how the website looks now with images added 🩵 #Django #Python #WebDevelopment #CSS #Frontend #LearningInPublic #100DaysOfCode #LexissLearns 🚀

🚀 Django Day 19 — Adding Static Files Today I learnt how to add styling to my Django project because the page was looking a bit bland 😅 — and of course, for learning purposes too! In Django, CSS files are called static files because they don’t change — they’re fixed resources like images, stylesheets, or scripts 🧱. So, I created a new folder in my challenges app (talked about in Day 4) and named it “static”. Inside that folder, I added my very first CSS file called “challenges.css” 🎉. To make Django recognize and use the CSS in my templates, I first had to create a space for the CSS block inside my parent template — base.html (from Day 16). I did this using Django’s block and endblock tags like this: {% block css_files %} {% endblock %} This basically reserves a special spot where each page can plug in its own CSS. Then, in my index.html, I linked the stylesheet like this: {% block css_files %} <link rel="stylesheet" href="{% static 'challenges/challenges.css' %}"> {% endblock %} The CSS rule I added in challenges.css was a simple one — it removes the bullet points from the list of months, giving it a neater and more professional look. So, if you compare the video from Day 15, where every month had bullet points • • •, you’ll notice that in today’s video those bullets are completely gone 🪄 — all thanks to the CSS I implemented through Django’s static files system. More to come 💻✨ #Django #Python #WebDevelopment #Frontend #CSS #100DaysOfCode #LearningInPublic #PythonJourney #lexisslearns 🚀

🚀 Django Day 20 — Adding Global Static Files Today, I learnt how to add global static files in Django — these are CSS files that apply to the entire project, not just a single app 🌍🎨. Just like how base.html serves as a parent template for all pages, a global static file serves as a universal style sheet that affects everything across the project. It’s a clean way to maintain consistent design and layout. ✨ So, I created a new folder named static in my root project folder (not inside any app). Inside it, I added a CSS file called styles.css 🎉. In that file, I wrote some styling rules — I wanted to change the font across the entire site (which I got from Google Fonts 💅) and also set the margin on all sides to 0 to give it a more aligned and modern look. Before it worked, I had to make a few changes in the settings.py file to make Django recognize static files located in the root folder, similar to how I configured it earlier for base.html 🧩. After saving and refreshing, everything looked neater — the new font gave it a clean, modern vibe, and the removed margins made the layout more balanced. 💻✨ There’s a short video below showcasing how the project now looks with the updated global styles. #Django #Python #WebDevelopment #Frontend #CSS #LearningInPublic #100DaysOfCode #TechJourney #lexisslearns 🚀

🚀 JavaScript Cheat Sheet - The Ultimate Quick Guide for Every Developer! I recently went through this amazing JavaScript Cheat Sheet created by Tilak (coding_dev_) - and it’s one of the best resources I’ve found for revising all the essential JS concepts in one place Whether you’re a beginner learning the basics or an experienced developer revisiting fundamentals, this cheat sheet is a perfect reference guide to strengthen your JavaScript knowledge. 💡 🧩 Key Topics Covered ✅ Basics of JavaScript — What JS is, where it’s used, and who created it (Brendan Eich, 1995) ✅ Data Types — String, Number, Boolean, Undefined, Null, BigInt, Symbol, Object ✅ Conditional Statements — if, else if, switch ✅ Loops — for, while, do-while ✅ Strings & Arrays — concat(), split(), indexOf(), substring() ✅ Math & Number Methods — Math.sqrt(), Math.random(), toFixed(), toPrecision() ✅ Date Object — Get date, time, and manipulate values easily ✅ Events — click, mouseenter, keypress, keyup, keydown ✅ Error Handling — try, catch, finally, throw ✅ DOM Manipulation — querySelector, getElementById, innerHTML, createElement ✅ Objects — Creation, access, and properties ✅ Regular Expressions — Pattern matching with meta characters and quantifiers ✅ Advanced JS Concepts — Closures, Generators, Promises, async/await, Recursion 💡 Why I Liked It ✔️ Covers all important syntax and examples in one compact PDF ✔️ Easy to understand — perfect for interview prep and last-minute revision ✔️ Clearly explains both basic and advanced JS concepts ✔️ Helps remember methods and operators quickly A huge thanks to Tilak (coding_dev_) for creating this clear and visually structured JavaScript Cheat Sheet. It’s a must-have for anyone improving their frontend or MERN stack skills 💭 Your Turn! Have you ever used a cheat sheet to revise coding concepts faster? Share your favorite JS resources or tools below 👇 #JavaScript #FrontendDevelopment #WebDevelopment #MERNStack #LearningJourney #CodingTips #Developers #LinkedInLearning #JSBasics #InterviewPreparation

🚀 Django Day 11 – The Index Page Today, we focused on building the index page of our Django project — the page that displays all the months as clickable links leading to their respective challenge activity views. To achieve this, we created a new path inside the urls.py file of the challenges app, which handles the logic for our monthly challenges. In order to make the page interactive, we used some basic HTML tags such as <ul>, <li>, and <a href="..">. Here’s how they work together 👇 🧩 <ul> creates an unordered list that serves as the container for all the months. 🔹 <li> represents each month as a list item within that list. 🔗 <a href=".."> makes each month name clickable, linking it directly to that month’s challenge activity page. By combining these, we created a dynamic list of all the months, where clicking on any of them takes the user straight to its respective challenge activity view. After writing the code, we started the development server (as explained back in Day 3) before saving the file. This allowed Django to automatically preview our work and point out any issues. Once everything was set, we navigated to the browser and entered: 🌐 localhost:8000/challenges/ That URL now leads to our index page, displaying all the months neatly listed and fully clickable. This marks an exciting point in the journey — my very first working website with Django. It’s simple, but it represents the foundation of web development with Django. From here, it’s all about consistency, understanding, and steady improvement. 🎥 A short video below shows how everything looks so far. #Django #Python #WebDevelopment #LearningInPublic #CodeJourney #TechJourney #lexisslearns

🚀 Django Day 18 — Wrapping Up Templates & Error Handling Today I wrapped up work on templates by checking my project for any remaining hardcoded HTML and converting those parts into reusable template files 🧩. I also created a custom 404.html template to handle wrong or non-existent URLs, so users see a friendly error page instead of the default debug message ⚠️. To display a custom 404 page I first experimented with render_to_string, which renders a template into an HTML string. For example, I used something like response = HttpResponseNotFound(render_to_string("404.html")) to return the rendered HTML as a 404 response. Then I learned about the Http404 exception. Instead of manually rendering and returning a 404 response, I can raise Http404("Page not found"), and Django will automatically use my 404.html template (if it exists) to show the error page. I found this approach cleaner and more idiomatic because: ✅ Less code — raising Http404 is shorter than building and returning a full response. ✅ Built-in behavior — Django’s error handling pipeline already knows how to find and render 404.html, so I don’t need to duplicate logic. ✅ Better separation — raising an exception keeps view logic focused on business rules; the rendering of error pages stays in Django’s standard flow. After switching to Http404, my error handling looks neater and follows Django best practices — and the custom 404 page now appears automatically when I test an invalid URL. It’s a small improvement, but it makes the app feel more polished. ✨ #Django #Python #WebDevelopment #LearningInPublic #100DaysOfCode #PythonJourney #lexisslearns 🚀

5 JavaScript Basics That Will Change Everything 1. var, let, and const (Scope & Hoisting): Just avoid using the var keyword. Understand how let and const alone can serve. This is Step 1 to writing clean code. 2. Closures (The "Memory" Trick): This one is tricky as you might mistake it for encapsulation in OOP, but it’s pure magic once you understand it. Think of it as a function having a secret memory of the variables from where it was born. It’s a reason advanced features work smoothly. 3. The Event Loop (How JS Multitasks): JavaScript is single-threaded. It can only do one thing at a time. So how does it fetch data from a server without freezing the whole app? You need to understand the Call Stack, Web APIs, and the Message Queue. This explains Promises! 4. The "this" Keyword (The Shapeshifter): This means something different depending on where you call a function from. Don't guess! Learn a little bit about how bind, call, and apply gives you total control. 5. Prototypal Inheritance (What Classes Are Hiding): You use class in modern JavaScript, right? Okay nice... Dig one layer deeper to see clearer. Prototypal Inheritance is the core mechanism JavaScript uses to share methods and properties. Understanding this makes debugging complex libraries much less painful. Which one of these made you feel like throwing your keyboard across the room when you first learned it? If you want me to get more elaborate each one of them, let me know in the comments! And if this was a helpful reality check, please leave a like and connect for more straight-up coding insights. #JavaScript #WebDevelopment #CodingBasics #Programming #BeginnerDev

🚀 Django Day 16 — Understanding Template Inheritance Today, I explored one of the core features of Django’s template system — Template Inheritance. 💡 Template inheritance allows me to create a base structure that other pages can reuse. Instead of repeating the same HTML layout across multiple files, I can define it once and simply extend it wherever it’s needed. This makes my code cleaner, more organized, and easier to maintain. 🧩✨ To implement this, I created a new folder named “templates”, but this time it’s located inside my main project folder — not inside my app folder. Inside this main templates folder, I created a new file called base.html, which acts as the foundation for all my other pages. Then I made my existing templates — index.html and challenge.html — inherit from this base file using the {% extends %} tag. This tag tells Django that the template should use everything from the base.html file unless it overrides specific sections. 🏗️ Inside the base.html, I used the {% block %} and {% endblock %} tags to define placeholder sections that other templates can fill with their unique content. For example, I wrote something like: {% block content %} Page-specific content goes here {% endblock %} In my index.html and challenge.html, I simply added: {% extends "base.html" %} {% block content %} Page content unique to this template {% endblock %} This setup allows both templates to share the same general layout — like the navigation bar, footer, or styling — while still keeping their unique content. 🌐 I also had to make a small adjustment in the settings.py file to let Django recognize my new templates folder. I did this by adding the path of the folder under the TEMPLATES setting. Once that was done, Django immediately picked up my base structure. ⚙️ It feels amazing to see how much cleaner and scalable my project is becoming and Happy last Sunday of the Month. 💪🔥 #Django #Python #WebDevelopment #CodeJourney #LearningInPublic #TechJourney #lexisslearns 🚀💻

The Missing Link Between Views and Templates That Changed My Django Flow At first, Django Templates looked like a riddle wrapped in curly braces. I remember the temptation: “Just return HTML from the view; it’s faster.” I almost lived off HttpResponse snippets; pasting HTML strings inside my views, until the day my view files turned into unreadable soup. That’s when I decided to crack the code behind templates: understand the logic, not just the syntax. What I found flipped the switch. Early on I used HttpResponse because it felt direct and simple: from django.http import HttpResponse def hello(request): return HttpResponse("<h1>Hello, Olawoyin</h1><p>Welcome</p>") It “works”; but it mixes presentation with logic and becomes impossible to maintain. Every tiny HTML change meant editing Python files. Reuse? Impossible. Testing? Painful. So I switched to render() to keep code clean, readable, and maintainable: from django.shortcuts import render def hello(request): return render(request, "test_app/hello.html", {"name": "Olawoyin"}) Why render() wins: • separates HTML (templates) from Python (views) • makes reuse and testing easier • supports context (variables) cleanly • keeps views focused on business logic, not markup Both patterns are valid, use what fits your app and team. And that’s where I paused my deep dive, right at the point where Django’s render() hands off to something even more powerful. In the next episode, I’ll be unpacking Function-Based and Class-Based Views; how they shape your project’s architecture and why understanding them changes the way you think about Django. Stay tuned, this next part ties everything together.

Day 2: Unpacking JavaScript Basics – From Interpretation to Objects (My #1YearOfCode Journey) #100xDevs Hey LinkedIn fam! 👋 On Day 2 of my deep dive into JavaScript, I explored why it's the web's powerhouse—browser-friendly, but with its own set of trade-offs. If you're a beginner or brushing up, here's my key takeaways. Sharing to #LearnInPublic and spark some convos. What's one JS "gotcha" that's tripped you up? 1. How JS Runs in the Browser Browsers execute HTML, CSS, and JS out of the box. Interpreted Language: JS converts and runs line-by-line—no upfront full compilation like C++ (which turns everything to binary). Rust compiles slow but runs blazing fast post-build. JS? Chunk it as you go, but runtime errors lurk—cue TypeScript for type safety! (Pro tip: Great for quick prototyping, but watch perf in big apps.) 2. Core Properties Dynamically Typed: Vars flex types mid-code (e.g., let x = 5; x = "hello";). Super flexible, but debug carefully. Single-Threaded: One task per CPU core at a time (ignores extras). Loops hog it, but the event loop handles async magic. Garbage Collected: Auto-manages RAM—frees unused data so you don't sweat memory leaks like in C++. Is JS "Good"? Yes for starters (easy entry), no for raw speed (overhead vs. C++/Rust). Tools like Bun are closing the gap—exciting times ahead! 3. Essential Syntax Variables: let (block-scoped, mutable), const (fixed value/type), var (function-scoped, mutable). Stick to let/const! Arrays: Aggregate multiples—let users = ["Ram", "Shyam"]; Access via 0-index: users[0]. Operators: == (value only, loose) vs === (value + type, strict)—always triple equals!