A bit behind on the anniversary note, but November 10th 2025 marked the one-year anniversary of the Initial commit for the project! Ohhhh boi, this has been a long journey, and hopefully, soon, a journey that will be coming to an end. I learned a ton from working on this project and will be doing a final post to conclude this series, but in this article, I want to focus on the beta for the app! Currently using Railway for deployment of the Web App and Tauri for the desktop app, but the desktop app isn’t built just yet. I thought it would be a simple launch alongside the web app, but I will get into why it wasn’t further along in this article. But here it is in all its glory:

» Creatures of Habit «

Get in there and create an account, stress the app out, and hopefully you can at least admire the work behind it, if not find some use for it. I’ve sent this to family and a few of my close friends to give some feedback before I let the world stress test it. Got some great feedback from all of them, and I also found PostHog to be an amazing tool when people actually started messing around in the app. Well worth the time investment there, and will be recommending them to anyone looking for a free analytics alternative. But after the few fixes and QOL improvements, I feel like it’s ready for others to criticize my app and judge me 😂. We’ll keep this one short.

“How do I get started?” you asked??

Well, let me tell ya, it’s easy as 1,2,3 (and 4).

Step 1 - Create an Account

Pretty straightforward step. Get your account and your creature created, then you’re off to the races

Step 2 - Create Your First Habit

You can create a new habit through the dashboard or on the /habits page.

Here is what the habit form will look like. Make your choices and set the habit to start on a future date as well.

Step 3 - Complete the Daily Quest

After you’re done adding habits, head over to the quests page and complete the Daily Quest. You gain a reward for completing the quest regardless of how many questions you get right, but of course, getting the correct answers has its benefits. If you get 3 answers right, you get a stat point boost and some additional experience. You get all 5 correct, and you get 2 stat points and even more exp. So definitely aim to get the right answers

.

(Maybe) Step 4 - Complete Any Habits That Were Due immediately.

Get to it!

The Delay For Desktop

That subtitle kinda sounds like an IT started a band on the side for fun….. A band I would prob go see lol. But anyway, the reason for the delay with the desktop app stems from two things: Code Signing and Distribution.

Distribution

I need to follow 2 different procedures for getting a proper distribution for both Windows and Mac (Sorry Linux folks ✌🏾). I want to get these into both the Microsoft and Apple stores for distribution, but for now, the easiest solution is to add installers for both of the operating systems and then just add a section for people to download it on the homepage or when you’re signed into the app. But in order to do this, I need Code Signing.

Code Signing 🫩

Apple is lame as hell. To list it on the App Store, you NEED to pay the $99/year Apple Developer.

Now I get it, this is meant to keep nefarious actors from spamming the app store with trash or corrupted apps. What I DON’T get is why the hell does using the free account still prevent me from notorizing my app, so it when it’s downloaded from the DMG, it’s gonna show up as “not verified” when opening the app. So I’ll prob still work on the free account before deciding to actually pay for this subscription. With Windows, I just need to create an account, and so far, I haven’t seen anything about a subscription, but if one pops up, they can kick rocks too.

Outside of the cost hurdle, the builds should be simple enough for both Windows and macOS.

Work So Far

Check out the projects repo → https://github.com/kdleonard93/creatures-of-habit if you wanna peep the work done since the last article or even since I first started. 495 COMMITS TOTAL!!! I’ve never seen a greener year in my life.

🥲 Super hot start and solid second half of the year. Proud of all the hours I put into this.

What’s Next?

So I have a couple more features that I want to add. One being a streak system, and another being FULLY dynamic quest questions and answers.

Streak System

The streak system was part of the plan since the beginning, but it became the least of my concerns when building this out, and I forgot to include it in my roadmap updates. So I wanted to add that as one of the final touches.

Dynamic Questions

Currently, the questions are partially dynamic. That being there is a bunch of pre-written questions and answers built in, and each quest refresh picks 5 random from the genre it chooses. I don’t want to use any AI for this since I don’t plan to actually make any money from this app to pay for it, so I’m going to need to rewrite my quest logic a bit to give the user a better sense of constant randomness.

After those two things and any bugs that pop up, I’m gonna be pretty much finished! I have the last 2 weeks off of the month, so the goal is to knock out these two things before the new year. Bunch of things are going on in my life outside of this project, so I’m not sweating if it’s not fully complete by the time the year is up, but I’ll try to give an update nevertheless.

Until next time ✌🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

We’re getting close to the end, folks! Most of the main features are complete and working, except for a handful of bugs that aren’t breaking the app. However, I’d like to address them before pushing this to production. For those curious, here are the features that have been built and completed:

- **Quest System** (DB, API, UI, rewards)
- **Authentication** (login, signup, password recovery, rate limiting)
- **Habit Tracking** (create, complete, categories, frequencies, streaks)
- **Character System** (creatures, stats, XP, leveling)
- **Equipment System** (schema, definitions, display) (Item creation/generation will be a future enhancement)
- **Dashboard** (daily progress, habit overview)
- **Settings** (preferences UI + backend)
- **Security** (rate limiting, security headers, CSRF)
- **Tauri Integration** (desktop-ready)
- **Test Coverage** (142 passing tests)

At first glance, by a layman, this might look like a very short list of completed features, but let me tell you, I’ve never worked so in-depth within the noted areas for any project I’ve worked on in the past. The amount of code needed to fulfill the specific definition of done for these milestones is considerably greater than if I were to just create a standard habit tracking app, caused by my own hand and ambition, lol. The Character Progression, Custom Authentication (should have just used BetterAuth 🥲 but I now have a tested example for when it DOES make sense to create my own auth system lol), Quest Systems, and Security/Test coverage are the main culprits for this added complexity. However, I don’t (fully) regret my decisions one bit! I’m 1 month away from my year of starting the work on it, and it’s looking like I’ll be hitting my timeline for when I wanted to have an MVP for this project. With that said, let's get into the main updates since Part 3.

Just a Few New Features

I feel most of my work since the last post has been more “re-working” of existing features, bug fixes, and enhancing a few areas, whether it was for UX or if it was for my own repo organization and efficiency. There were a few features introduced, though, that wrapped up the feature work needed for the MVP.

• Quest System

• Waitlist

• Dynamic Navigation

These ^ are the features that add the final pieces to MVP, and the bulk of the addition was for the Quest System. That feature required the reworking of a few of my existing components, like the stat allocation system, character progression, and the need for an update to the schema, let alone building out the quest system logic. I honestly didn’t know how I’d approach this at first, but I figured I’d keep it simple.

Quest System

How the Quests Work

The quests are generated on a daily basis, and the user gets one quest per day. They are not entirely dynamic at the moment, but the order and correct answers are randomized. Each question has a skill check that has a chance of success based on the user’s corresponding stat. There are 3 levels of rewards for completing the quest.

• Less than 3 questions right: 50 EXP

• 3 out of 5 questions right: 100 EXP + 1 Stat Boost point

• 5 out of 5 questions right: 100 EXP + 2 Stat Boost points

Once the quest is complete, you’ll see the start button greyed out and a (broken) time displayed on the page. I’ll eventually get around to fixing the timer, but not too worried about that for the MVP.

The Overhaul Needed for the Quest Service

Off the rip, new Quest Service tables were needed:

Okay, boring part out of the way. If you're curious about how those tables were built out, parse through the GitHub repo to your heart’s desire. What I want to get into is the challenges and nitty-gritty of how the quest system works under the hood.

The Daily Quest Generation Challenge

The first major hurdle was figuring out how to generate "one quest per day" without creating duplicates or letting users spam quests. So I took this approach:

Template-Based Generation: I didn’t have the time (or, quite frankly, the skillset 🥲) to do what I wanted, which was to have an LLM generate unique questions and answers at random. So I created a seeding system that populates quest_templates with pre-written quest scenarios. Each template includes:

• A narrative setting (forest, dungeon, city, etc.)

• Difficulty level (easy, medium, hard)

• Base reward values

Daily Instance Creation: The getDailyQuest() function in questService.ts checks if the user already has a quest for today by:

• Querying for any quest instances created today (using date comparison)

• If none exists, creates a new instance from a random template

• Generating 5 questions using the generateQuestQuestions() helper

This approach got me as close to what I wanted within my capacity: consistent quest quality from templates, but enough randomization to keep things fresh.

Stat Check System: The Feature That’s Supposed to Hook Ya.

So up until this point, the stats didn’t really mean anything. Adding the skill checks for the quest system gave these stats purpose in life. The only stat that really meant anything was “Constitution” but it only increased the user’s health…….which is never altered since there are no battles lol, so in the end it was useless too. But while stats are going to be connected in the future with other features if/when they are added (Equipment requirements, Boss Fights, etc.), having them connected to the Quests is good enough for MVP.

The logic works like this:

const userStat = userStats[question.requiredStat]; // e.g., user's strength = 12
const threshold = question.difficultyThreshold; // e.g., 10 for medium difficulty
const successChance = Math.min(0.95, Math.max(0.05, userStat / threshold));
const passed = Math.random() < successChance;

So if you have 15 strength and the question requires 10 strength, you have a 95% chance of success (capped at 95% to keep things interesting). But if you only have 5 strength, you're looking at a 50% chance. This creates a real incentive to invest in your stats through the stat boost point system.

The Stat Boost Point Economy

This is where the quest system ties back into the progression loop. Completing quests with 3+ correct answers awards stat boost points, which users can spend to permanently increase any stat. This created a nice feedback loop:

1. Complete habits → Gain XP → Level up

2. Take daily quest → Answer questions (success based on stats)

3. Complete quest → Earn stat boost points

4. Spend points to increase stats

5. Higher stats → Better quest success rates → More points

But this also meant I had to refactor the entire stat system. Previously, stats were just static values from character creation. Now they needed to be:

• Mutable (users can boost them)

• Tracked separately (base stats vs. equipment bonuses vs. racial bonuses)

• Calculated dynamically (effective stats = base + race + class + equipment)

I added a statBoostPoints column to the creature_stats table and created new API endpoints:

• GET /api/character/stat-boost-points - Fetch current stats and available points

• POST /api/character/boost-stat - Spend a point to increase a stat

Question Generation: The Rule-Based Approach

I initially considered using an LLM to generate quest questions dynamically, but that introduced too many variables (API costs, latency, content moderation, consistency). Instead, I built a rule-based question bank system in questHelpers.ts.

Each stat type has a pool of ~10-15 question templates with thematic choices:

• Strength questions: Physical challenges.

• Intelligence questions: Puzzles and logic problems.

• Wisdom questions: Moral dilemmas and perception checks.

• Charisma questions: Social situations and persuasion.

• Dexterity questions: Agility and precision tasks.

• Constitution questions: Endurance and resilience tests.

The generateQuestQuestions() function randomly selects 5 questions (one per stat, or weighted by quest difficulty), shuffles them, and randomizes which choice (A or B) is correct. This gives the illusion of variety without the complexity of true procedural generation.

The Integration Testing Headache

Getting the quest system done was only half the battle. I ran into multiple roadblocks getting it to work reliably in the CI workflow.

The integration tests initially failed in GitHub Actions because I was using mock Turso database URLs that didn't actually exist. The tests would try to connect to libsql://mock-db.turso.io and get HTTP 404 errors. The solution was to:

1. Switch to local SQLite databases for testing (file:test.db)

2. Create test-specific versions of quest service functions

3. Set up proper test data with users, creatures, stats, and quest templates

4. Ensure cleanup between tests to avoid state pollution

I also had to update the test database schema in test-db.ts to include all the quest-related tables and their foreign key relationships. This was tedious but necessary to catch bugs before they hit production.

The Reward Calculation Logic

The reward system needed to be fair, but also needed to incentivize good performance. Behold the simple as hell tier system:

const correctAnswers = questInstance.correctAnswers;
let expReward = questInstance.expRewardBase; // 50 XP base
let statBoostPoints = 0;

if (correctAnswers >= 5) {
  expReward += questInstance.expRewardBonus; // +100 XP
  statBoostPoints = 2;
} else if (correctAnswers >= 3) {
  expReward += questInstance.expRewardBonus; // +100 XP
  statBoostPoints = 1;
}

This creates clear breakpoints: getting 3 right is the minimum for bonus rewards, and perfect scores are doubly rewarded. It also means even if you fail the quest, you still get something (50 XP), so it never feels like a complete waste.

Things That Could Improve the Quest System

1. Use a state machine for quest status transitions (available → active → completed) to prevent edge cases

2. Add quest categories (combat, exploration, social) to give users more variety

3. Implement a cooldown system instead of strict "one per day" to be more forgiving of different timezones

4. Cache quest questions on the client to reduce API calls during the quest flow

5. Add quest history so users can see their past performance and track improvement

Not going to even think about these, though, until after this is cleaned up and ready for production. These improvements would just be for if people actually start using this app…..which I doubt will happen 😄.

Waitlist Feature

I wanted a way to gather a bit of data related to interest in this app. This feature is more so a test to see if folks are interested in things I’m making, and from what I’ve researched about people creating products or applications, is that the waitlist is the easiest and quickest field test for interest in your product. I don’t think too many people will actually sign up, but the hope is that a few will, and it will give me a bit of insight into how to effectively use a waitlist for the next thing I build. The way I built mine out is a bit different from how one might typically set it up due to the stack I used, but here is the gist of how this was set up.

The Database Schema: More Than Just Emails

Most waitlists just capture an email address and call it a day. But since I'm treating this as a learning experience, I wanted to capture data that would actually be useful for understanding any interested users:

user_waitlist {
  id: UUID
  email: unique, required
  ipAddress: optional
  userAgent: optional
  referralSource: optional
  subscribedAt: timestamp
}

The analytics fields (ipAddress, userAgent, referralSource) give me insights into:

• Geographic distribution of interest

• Device types (mobile vs. desktop)

• Traffic sources (social media, direct, referrals)

These are all optional and anonymized in logs, so I'm not storing anything sensitive, but they'll help me understand where interested audiences are coming from and what devices they're using.

Rate Limiting to Swat 👋🏾 Spam

One thing I learned early on is that any public-facing form needs rate limiting. Without it, someone could easily spam the database with fake emails or run a script to fill it with trash data.

I reused my existing rateLimit middleware (which was built for the authentication endpoints) and applied it to the waitlist API:

await rateLimit(event, {
  windowMs: 60 * 60 * 1000, // 1 hour window
  maxRequests: 5,           // 5 submissions per hour
  message: 'Too many waitlist submissions. Please try again later.'
});

Five submissions per hour felt sufficient—strict enough to prevent abuse, but lenient enough that someone who mistypes their email isn't locked out.

The Duplicate Email Problem

This was one of those "seems simple, but actually isn't" problems. What happens when someone tries to sign up twice? I needed to handle three scenarios:

1. New email → Add to database, show success

2. Duplicate email (caught by my query) → Show "already signed up" message

3. Duplicate email (caught by database constraint) → Show "already signed up" message

The tricky part was that SQLite's unique constraint throws an error on duplicates, but I wanted to handle this gracefully without showing users a scary error message.

My solution was to check proactively first:

const existingEntry = await db.select()
  .from(schema.userWaitlist)
  .where(eq(schema.userWaitlist.email, email))
  .limit(1);

if (existingEntry.length > 0) {
  return json({
    success: true,
    message: 'You\'re already on our waitlist!',
    alreadySignedUp: true,
    redirectTo: '/waitlist/thank-you'
  });
}

Then catch any constraint violations as a fallback:

if (message.includes('unique') || message.includes('constraint')) {
  return json({
    success: true, // Still return success!
    message: 'You\'re already on our waitlist!',
    alreadySignedUp: true,
    redirectTo: '/waitlist/thank-you'
  });
}

Notice that I return success: true even for duplicates. From the user's perspective, their goal (being on the waitlist) is achieved, so it's a success. This was a UX decision that took me a minute to arrive at. Initially, I was returning an error, but that felt wrong.

Privacy-Conscious Analytics with PostHog

I wanted to track waitlist conversions without storing raw email addresses in my analytics platform. The solution was to hash emails on the client side before sending them to PostHog:

async function anonymizeEmail(email: string): Promise<string> {
  const emailHash = await crypto.subtle.digest('SHA-256', 
    new TextEncoder().encode(email));
  return Array.from(new Uint8Array(emailHash))
    .map(b => b.toString(16).padStart(2, '0'))
    .join('');
}

posthog.capture('waitlist_submission', {
  email_hash: emailHash,
  success: true,
  redirectTo: result.redirectTo || null,
  error: null
});

This gives me conversion tracking and funnel analysis without compromising user privacy. The hash is one-way, so I can't reverse it to get the original email, but I can still track unique conversions and identify patterns. This felt like the right approach for a privacy-conscious app.

The Thank You Page: Adding Social Proof

After submission, users are redirected to a thank you page that shows how many people have joined the waitlist:

const waitlistCount = await db.select({count: count()})
  .from(userWaitlist);

return {
  potentialHeroes: {
    usersJoined: waitlistCount[0]?.count ?? 0,
    launchDate: 'Q1 2026',
  }
};

"Join {# of waitlist users} early adopters" is more compelling than just "Thanks for signing up" and it’s a nice lil tally for the public to see how many other people would be enjoying the app with them.

The count is queried server-side on every page load, so it's always up-to-date. For a high-traffic site, I'd probably cache this, but for a pre-launch waitlist, the real-time count feels more valuable.

Automatic Referral Source Tracking

One feature I'm particularly happy with is the automatic referral tracking:

const referralSource = validatedData.referralSource || 
  event.request.headers.get('referer') || 
  'direct';

This automatically captures where users came from, even without custom UTM parameters. I can still add custom referral parameters (like ?ref=twitter) to track specific campaigns, but the automatic fallback to the HTTP referer header means I get data even without them.

This will help me answer questions like:

• Which social media platform drives the most signups?

• Are people finding me through organic search or paid ads?

Input Validation: Keeping Data Clean

I used Zod for runtime validation of the email input:

const waitlistSchema = z.object({
  email: z.string().email('Please enter a valid email address'),
  referralSource: z.string().optional(),
});

This catches malformed emails before they hit the database and provides user-friendly error messages. The validation runs server-side, so even if someone bypasses the frontend validation (by using curl or Postman), they can't submit garbage data.

What I Learned

Building this waitlist feature taught me a few things:

1. Rate limiting is non-negotiable - Any public form needs protection from spam

2. Error handling is UX - How you handle duplicates and errors matters as much as the happy path

3. Analytics need privacy - You can track conversions without compromising user data

4. Social proof works - Showing the signup count makes the page feel more alive

There are a handful of things I still need to add though:

• Email verification

• A referral program (…..maybe)

• More fields to capture user interests or feature requests

• An admin dashboard to view signups and export emails

But for a first attempt at a waitlist? I'm happy with how it turned out. It's secure, it handles edge cases, and it's already set to provide me with useful data about who's interested in the app.

Dynamic Navigation Update

This one is cut and dry, I updated the nav to be different for folks who aren’t signed in and for people who are. Initially, most of the nav items were all related to a user’s profile, quests, and creature info. So, I needed to improve the UX so that the navigation that showed for the user was usable and useful.

Unauthenticated User

For unauthenticated users, the user still sees the homepage, but there is a brand new Waitlist landing page they can go to where they can sign up. But notice that the nav only has 4 links, which are all informational:

• Waitlist

• Features

• How It Works

• FAQ

These links are also in the footer, but this gives the user more visibility to informational pages about this app and what would eventually include information about myself and Digital Dopamine LLC 😏.

There’s not much else to get into regarding this feature since most of the work was for the waitlist portion, but here is the portion of my Header.svelte component was updated:

    // User navigation items
    const userNavItems = [
      { href: '/dashboard', label: 'Dashboard' },
      { href: '/habits', label: 'Habits' },
      { href: '/character/details', label: 'Character' },
      { href: '/quests', label: 'Quests' }
    ];

    // Marketing navigation items (shown when not authenticated)
    const marketingNavItems = [
      { href: '/waitlist', label: 'Waitlist' },
      { href: '/features', label: 'Features' },
      { href: '/how-to-play', label: 'How It Works' },
      { href: '/faq', label: 'FAQ' }
    ];

    // Auth items for consistent usage
    const authItems: Array<{ href: string; label: string; variant: ButtonVariant }> = [
      { href: '/login', label: 'Log in', variant: 'secondary' },
      { href: '/signup', label: 'Sign up', variant: 'default' }
    ];

    const path = $derived($page.url.pathname);
    const isAuthenticated = $derived(!!$page.data.user);
    const navItems = $derived(isAuthenticated ? userNavItems : marketingNavItems);

The header uses Svelte 5's $derived runes to automatically switch between two navigation menus based on whether the user is authenticated. Authenticated users see the “user navigation”, while visitors see “marketing pages”. This keeps the navigation clean and contextually relevant.

Cleanup and Stompin’ on Bugs

Was two-stepping on bugs so good, Orkin called and asked for consulting. And if you need a visual example of what I mean…..

This ^…….This is how I was steppin’ on em 😂. All jokes aside, there were a TON of bug fixes that went into place over the last couple of months, as well as some overall cleanup. Removed a good amount of code that had no purpose anymore….or at all lol. I also made a few visual updates to the character creation so it feels a bit more prod-ready.

Icons + Logo

All icons, including my logo, got an update. I’m leveraging game-icons in place of my custom-made (and very sloppy-looking 🥴) icons, I made at the start of this project. The OG logo, while not sloppy, still looked a little too pixelated for what I was aiming for, so I used another random icon from game-icons and altered it to give it a custom color scheme. It’s all still SVGs, so that’s a plus, and if needed, I can go in and customize each icon as I see fit. But for now, most of them will just remain the default color of white with black outlines.

Looking Ahead

As we approach the finish line for MVP, there are just a few main things I want to take care of before making a Beta live for people to test out:

1. API Endpoint Fixes

2. Fix Failing Tests

3. A bit of UX + UI polishing

4. Basic documentation

This should be about 2 to maybe 3 weeks of work, depending on how busy I am with other life responsibilities. But there is a chance I get some additional free time earlier than that and might power through the final bit of work I want to complete. But that’s it for now and the next post you’ll see from me is when the app is live on a very cool URL 😉.

Until next time, folks. Be easy and keep pushin’ 🤘🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Sup folks, it's been nearly two months since my last post, and a ton of work has been done on “Creatures of Habit”. It’s so much that by the time I went through every little thing, I’d lose the attention of 5 people still keeping up with my articles.

But bad jokes aside, I’ve worked on numerous fixes and improvements to the UI, set up the base work for staging deploys, implemented Tauri for mobile and desktop app capabilities, dedicated local db setup (in progress), and Auth0 implementation (research, no code yet). I’ve also been doing things to situate myself in the proper position if I ever want to ship this app. It’s growing into something I never imagined I’d be able to make, but I’ve been loving the journey. So I’ve officially registered my business “Digital Dopamine LLC” and trademarked it ✊🏾. I’ve been having discussions with some peers of mine, and it seems we are all clear that we want to be able to work for ourselves at some point. They all have different professions, and when combining our heads and skills, we see a lot of opportunity to be had, even during these troubling times here in the States.

With that said, I’m going to cover the following in this article:

• An overview of the code that has been committed.

• Background on the LLC and Trademark decision

• Other project ideas that sprouted from the conversations I’ve had. None of which I’ll be starting before getting this app to a good spot.

So let’s get into it.

Code Updates Galore

Most of the code updates related to UI fixes, theme changes, big improvements to data integrity, improved performance, with some maintenance & debugging updates to top it off. Like always, you can check out the pull requests merged in since my last post (May 27th) → https://github.com/kdleonard93/creatures-of-habit/pulls?q=is%3Apr+is%3Aclosed. Below is a quick screenshot for the folks who don’t know their way around GitHub.

I follow the same flow of putting every update behind a PR, even if it’s just me working on this project. My current automated testing suite does a great job of helping me catch issues before successfully committing and pushing. This helped me prevent a few breaking changes when updating packages and Svelte versions, amongst other things like lint errors.

Changes to the Theme

There have been many changes to the theme. Mostly visually, but there are a few things updated with the logic on some components. The main one being the Progress bar. In my last article, I mentioned I added the progress bar along with some other UX improvements for the Dashboard. But I discovered a handful of bugs with the Progress bar, like issues with habit completions, how the state is updated when new habits are added after already completing a few or all habits, and resetting that state each day. It was tricky as hell. I had an issue with what I was retrieving from the DB as a completed VS active habit. The math didn’t account for new habits being added, so I pretty much had an update for it to take: (number of rows where completed = true / total number of rows) * 100. This way, once new habits were added, the total changed, fixing my calculation. Then I was able to pass the function’s return down as a prop and assign the value to the Progress Bar UI that’s on the user’s Dashboard.

Outside of that, most changes were just a bunch of CSS and Tailwind config updates. Below is a quick video of me touring the “New and Improved Design!!!!!!”:

Taurica, Taurida, and Tauri(s)

If the section title doesn’t make sense, check out the wiki. When trying to make a unique title, I learned that the Tauri were ancient people who settled in the Crimea peninsula. Not sure if the Tauri framework was inspired by the Tauri people, but it made for a good title 😄.

Anyway, to get back on track, I wanted to discuss Tauri and why I’ve integrated this framework into my app. Better yet, I’ll just post their sales pitch below:

Tauri is a framework for building tiny, fast binaries for all major desktop and mobile platforms. Developers can integrate any frontend framework that compiles to HTML, JavaScript, and CSS for building their user experience while leveraging languages such as Rust, Swift, and Kotlin for backend logic when needed.

Basically, this framework will allow me to launch this app on Mobile and Desktop as well as Web. The only additional headache is to at least learn to understand Rust. So far, I have not needed to write anything extensive in Rust that wasn’t a part of their SvelteKit setup docs. It was pretty smooth to get it implemented as well. Just an add of the cli with pnpm add -D @tauri-apps/cli@latest a quick pnpm tauri init did about 85% of what’s needed to make this app cross-platform. The remaining 15% was updated by me, but very minimally, and there is a dope repo I found from this post in the sveltejs subreddit: https://github.com/alysonhower/tauri2-svelte5-shadcn. Which was perfect for my project since I’m using Svelte v5 as well. So referencing his config files helped a lot in getting mine set. That’s it! I’d say I’m 95% cross-platform ready, with the remaining 5% saved for figuring out how to push this to production once I get to that point.

Small But Impactful

The rest of the code changes were pretty small in terms of functionality, but there were heavy visual upgrades, Product & Support pages built out, and dummy content added to them. There was also some research done on tools I wanted to add, like Auth0, as well as get a local DB setup, so I’m not constantly manipulating the real DB. A local DB is even more important to have before this app launches, so I can test properly after it’s live. I won’t get into the details of the code added for this part since it seems unnecessary, but you can see me go through the pages in the video above.

LLC Me, Baby

Not too long ago, at my place of work, which currently pays my bills, there was an available company with Rocket Lawyer. During that meeting, I learned that as a Cars.com employee, I get a few free benefits with their services, one being setting up an LLC. It just felt like the right move to do, considering how rapidly things are changing in the industry now and in our society in general. There’s no telling when Rocket Lawyer’s partnership might be replaced with a different one.

So I pulled the trigger, and while I should have planned a big spend like this a bit better 😅, it was relatively affordable in terms of securing the name of your business and trademark. So the plan is to release any products/projects moving forward under Digital Dopamine. I’ve had the name for a while, as my portfolio website’s URL is digitaldopamine.dev, and it hits home for me. Today’s digital age is all about quick and fast dopamine hits from social media, gaming, or any form of visual entertainment, and I saw no better name for my company that will be building apps and tools for the geeks around the web. Which leads me to the next project I started discussing with some close friends of mine.

New App…..For Next Year

One of my good friends loves to cook and wanted to start a smash burger business in the burbs of Chicago, since there are no good smash burger locations once you leave the metropolitan area. I initially offered just to make his landing page, but after talking through the idea for an hr or so, I asked if there was any app that he would love that isn’t out at the moment. We found an app called RecipeMe, and while that app does a lot of good things, it was missing one big feature. Not that they will be reading my article, but I don’t want to say exactly what feature we were talking about, but it would require an LLM implementation, and I have a few ideas to branch off of that as well, that’s catered to our culture of cooking. One thing I need to do is start researching the OG recipes from our parents and grandparents and get that data stored in a Notion doc or something. That way, once I’m ready to start building it, I’ll be prepped with unique homemade recipes (hopefully) not found anywhere else on the internet.

Looking Ahead

That’s about it for this write-up. Please check out the repo if you want a deeper dive into what code has been implemented since Part 2. Creatures of Habit is coming together nicely, but I still have a lot of work left to do. A quick look at what’s ahead:

1. Push Notifications: I need to figure out how to get push notifications working on mainly the Desktop and Mobile apps, and then follow that up with web.

2. User Management Enhancement: I need to implement a “Forgot Your Password” feature as well as a “Delete Your Profile” feature, along with other user management improvements.

3. Offline Support Research (cont.): While we have Tauri set up, we still need to get an “Offline First” implementation in.

Until next time, folks. Be easy and keep pushin’ 🤘🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

As you can see from the new terrain in this cover image vs the last article's, we've made it out of the "Wacced out Woods" and have arrived at "Finessin' Fields". Time to gear up ✊🏾.

Over the last couple of months, I've been working on improving the quality of the code and my testing implementation. I also needed to get a workflow set for automation since this is turning into a pretty big codebase. I never knew how much would need to go into an app like this…..or this is just a lesson on choosing a more fitting tech stack next time lol.

For this write up I’ll go over the following:

• 🧪 Testing & Quality:

  - Test Driven Development (TDD) Implementation- Component Testing Templates- TypeScript Import Fixes

• 📊 User Experience:

  - Responsive Dashboard with Daily Habit Overview- Visual Progress Bars for Habit Completion- Quick-Complete Functionality from Dashboard

• 🔄 Developer Workflow:

  - Biome for Code Quality (Replacing ESLint)- CI Workflow with TypeScript & Style Checks- Pre-commit & Pre-push Hooks

As always, you can check out the code on the repo here → https://github.com/kdleonard93/creatures-of-habit. Let's dive into the details Testing & Quality Assurance

One of the biggest shifts in my development approach has been embracing Test Driven Development (TDD). Word on the street is that for the type of app im making, which will be extremely component heavy, benefits from this type of approach to avoid unforeseen troubles down the line when I have actual users….which will be friends, family, and whoever is bored enough to sign up 😏 so maybe i could have stuck with my OG approach. I digress, the point is implementing this way for testing required me to yet again, learn something new and say goodby to some other knowledge i recently gained for a totally diff project or for the job that actually feeds me.

Test Driven Development Implementation

So here I am, embracing the TDD workflow: write tests first, implement the minimum code to make them pass, then refactor while keeping tests green. This approach has already caught several bugs before they made snuck their way into a future production build and has forced me to think more clearly about component interfaces and responsibilities.

The TDD cycle looks a little something like this:

1. Write a test that defines how the code should work

2. Run the test (it should fail)

3. Write the minimum code to make the test pass

4. Run the test again (it should pass)

5. Refactor the code while keeping tests passing

6. Repeat for additional features or edge cases

Here's a real example from my implementation of the DailyProgressSummary component:

// First, I wrote the test
it('calculates completion percentage correctly', () => {
  const habits = [
    { id: '1', completedToday: true },
    { id: '2', completedToday: false },
    { id: '3', completedToday: true }
  ];

  const { getByText } = render(DailyProgressSummary, { props: { habits } });
  expect(getByText('67%')).toBeInTheDocument();
  expect(getByText('(2/3)')).toBeInTheDocument();
});

Then I implemented the component with just enough code to make the test pass:

<script lang="ts">
  export let habits: { id: string, completedToday: boolean }[] = [];

  $: totalHabits = habits.length;
  $: completedHabits = habits.filter(h => h.completedToday).length;
  $: completionPercentage = totalHabits > 0 
    ? Math.round((completedHabits / totalHabits) * 100) 
    : 0;
</script>

<div class="bg-card p-3 rounded-lg border shadow-sm flex flex-col items-center">
  <p class="text-sm font-medium mb-1">Today's Progress</p>
  <div class="flex items-center gap-2">
    <div class="text-2xl font-bold">{completionPercentage}%</div>
    <div class="text-muted-foreground text-sm">({completedHabits}/{totalHabits})</div>
  </div>
</div>

Component Testing Templates

To standardize my testing approach, I created reusable testing templates for different types of components:

• UIComponentTest: For Svelte UI components.

• APIEndpointTest: For API endpoints and server routes.

• UtilityTest: For utility functions and helpers.

These templates include best practices, common test patterns, and examples that make it much easier to write consistent, high-quality tests. No more staring at a blank file wondering how to structure a test!

TypeScript Fun & Import Fixes

I ran into an annoying issue with TypeScript not recognizing Svelte component imports in test files. Here’s the error:

Cannot find module '$lib/components/habits/HabitForm.svelte' or its corresponding type declarations

Initially, I used the @ts-ignore hack to bypass the issue, but I knew that wasn't sustainable. After some research, I implemented a proper solution by creating type declarations for Svelte components in my test environment. This ensures TypeScript understands the imports and provides proper type checking. The svelte.d.ts is below for a quick reference:

// General declaration for all Svelte files
declare module '*.svelte' {
  import type { ComponentType } from 'svelte';
  const component: ComponentType<any>;
  export default component;
}

// Specific declaration for the component causing the error
declare module '$lib/components/dashboard/DailyProgressSummary.svelte' {
  import type { ComponentType } from 'svelte';
  const component: ComponentType<any>;
  export default component;
}

// Add other specific component paths as needed
declare module '$lib/components/habits/HabitForm.svelte' {
  import type { ComponentType } from 'svelte';
  const component: ComponentType<any>;
  export default component;
}

// Server module declarations
declare module '$lib/server/streaks/calculations' {
  export interface StreakStatus {
    streakMaintained: boolean;
    daysInStreak: number;
    streakWeeks?: number;
  }

  export interface StreakUpdateResult {
    currentStreak: number;
    longestStreak: number;
    lastCompletedAt: string;
  }

  export function determineStreakStatus(
    habitData: { id: string; userId: string; frequencyId: string },
    currentDate: Date
  ): Promise<StreakStatus>;

  export function updateStreakAfterCompletion(
    habitId: string,
    userId: string
  ): Promise<StreakUpdateResult>;
}

declare module '$lib/server/db' {
  type MockFunction<T = any> = T & {
    mockReturnThis: () => MockFunction<T>;
    mockImplementation: (fn: (...args: any[]) => any) => MockFunction<T>;
    mockImplementationOnce: (fn: (...args: any[]) => any) => MockFunction<T>;
    mockReturnValue: (value: any) => MockFunction<T>;
  };

  type MockDB = {
    select: MockFunction<() => MockDB>;
    from: MockFunction<(table: any) => MockDB>;
    where: MockFunction<(condition: any) => MockDB>;
    orderBy: MockFunction<(field: any) => MockDB>;
    limit: MockFunction<(num: number) => MockDB>;
    update: MockFunction<(table: any) => MockDB>;
    set: MockFunction<(data: any) => MockDB>;
    execute: MockFunction<() => any[]>;
  };

  export const db: MockDB;
}

I think there is an update being proposed that should make the components accessible from server files, making imports in test files much simpler.

📊 User Experience Enhancements

Responsive Dashboard with Daily Habit Overview

The dashboard has been completely revamped to provide users with a clear overview of their daily progress. The centerpiece is the new component that shows:

• Overall completion percentage for the day

• Visual progress bar showing completion status

• Fraction of completed habits (e.g., "2/5")

This gives users immediate feedback on how they're doing for the day, creating that dopamine hit when they see their progress increase.

But here’s the kicker…..it doesn’t actually work as expected 😂. And that pointed out a major issue in the component tests that I’ve created thus far, which is that they work fine when using mock data but when trying to use the actual data stored in my db, I get a bunch of new errors that I haven’t been able to figure out. For now though, the mock data will be just fine and this is just gonna have to be one of the areas I come back to in the future.

Visual Progress Bars for Habit Completion

Every habit now has its own progress visualization that clearly shows completion status at a glance. The dashboard implementation provides immediate visual feedback on habit tracking progress.

The progress bars are complemented by a color-coding system based on the habit's difficulty:

• Easy habits: Green

• Medium habits: Yellow

• Hard habits: Red

This intuitive color scheme helps users quickly identify the difficulty level of each habit, making it easier to prioritize and manage their daily tasks. The visual indicators add both functionality and a splash of color to the interface, enhancing both usability and visual appeal.

Quick-Complete Functionality from Dashboard

Users can now complete habits directly from the dashboard with a single click, eliminating the need to navigate to individual habit pages. This seemingly small change has dramatically improved the user experience - it's all about reducing friction for those daily habit completions

The quick-complete buttons use the existing success variant in the Button component, maintaining visual and logical consistency.

🔄 Developer Workflow Improvements

Biome for Code Quality

I've switched from ESLint to Biome for code quality checks. Biome is faster, more integrated, and provides both linting and formatting in a single tool. The configuration is simpler, and it plays nicely with the rest of my toolchain. I also can’t help myself when I see newer tools get a bunch of praise.

Setting up Biome was straightforward. Example:

// package.json scripts
"format": "biome format --write .",
"format:check": "biome check",
"lint": "biome lint .",
"lint:fix": "biome lint . --apply"

CI Workflow with TypeScript & Style Checks

The continuous integration workflow now includes:

1. TypeScript type checking

2. Biome code style checks

3. Automated testing

4. Build verification

So now I have a pretty decent set of tests that need to pass before the PR is merged into master. The CI workflow runs on GitHub Actions and prevents merging code that doesn't meet the quality standards.

Pre-commit & Pre-push Hooks

To catch issues before they even reach the repository, I've set up pre-commit hooks that run:

• TypeScript type checking

• Biome style checks

• All of the tests I have set up

And a pre-push hook that ensures the project builds successfully before pushing code.

This multi-layered approach to quality assurance has already prevented several bugs from entering the codebase and has made the development process more robust. I’ve gained most of my CI knowledge from the work being done at my current company, and it’s been extremely helpful in catching errors as I continue developing the app.

Quick Peek of What’s Ahead

While I've made significant progress on the engineering practices and user experience, there's still plenty on the roadmap:

1. Complete the XP System: Implement experience points for character progression and refine creature creation statistics.

2. Enhance Dashboard Visualizations: Add streak tracking and long-term progress visualizations, plus fix habit completion data accuracy.

3. Offline Support Research: Investigate offline capabilities for potential mobile app development.

With our improved development practices in place, we're well-positioned to implement new features efficiently and maintain high quality standards….well that’s he hope at least 😉. Stay tuned for what's next on deck 🤘🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Hot damn, looking back at all the incremental work done on my project, can’t help but pat myself on the back because this is the first app I have that has a SOLID foundation from front to back. Now by solid foundation, I mean most of my core systems were built out and (most 😉) have tests to compliment them. Not only that, the tech stack used required me to create and manage my own schemas, authentication, and session handling. Compared to my last project “Leo Ledger”, the scope itself has been completely different, in size and complexity. Trying to mesh a classic habit tracking app with RPG-like mechanics to gamify it has been my biggest challenge yet. A lot of this has been fun to learn and understand Svelte 5 and TypeScript a bit more, but I’m no expert now and have had my fair share of rage…..which feels like a right of passage with learning TypeScript lol.

Lo and behold, I’ve reached a major milestone, but am far from finished. In this article, I want to go over the new features added since my last entry:

• 🔮 Features:

  - Habit Completion

  - XP Setup.

  - Notifications System, Reminder, & Testing Route.

  - PostHog Implementation (Analytics Tracking).

• 🪚 Fixes:

  - Edit Habit Functionality Fix.

  - Logout Route POST action Fix for 1 of 2 CTAs.

• 🦾 Enhancements:

  - New theme to give the app a bit of personality (NOT FINAL).

  - Updated the Signup Route’s CTA with {isSubmitting} for a better UX.

  - Implemented Toast in the app’s notification system.

  - CodeRabbit (Temporary; Experimenting with it.)

As always you can peep the code on the repo here → https://github.com/kdleonard93/creatures-of-habit. Let’s get started with the Features!

🔮 New Features + Enhancements

Everything in my feature setup seems like it might be a small portion of the grand scope of the project but let me tell ya, that wasn’t the case.

Habit Completion & XP Feature

This one was a bit of both a feature and an enhancement. The feature of adding a completed route and functionality enhanced the overall habit management system. Now there is a graveyard where all of your completed habits can go. On the /completed route, you can permanently delete those habits from the database. This ties into the XP feature since upon completing a habit, depending on the difficulty, you gain experience points!
However…….those points are worthless at the moment 😂. The XP feature isn’t fully fleshed out yet, but there is activity in the console with proper fetch requests. Below, you can see an example of 1 completed and 1 deleted habit (Need to add an indicator for each to differentiate them in the graveyard….that’s what I’m calling the /complete route from now on). Once I permanently delete one, you can see all of the action in the console:

• Once I click on “Delete Permanently” and confirm my choice, the application sends a DELETE request to the server.

• After the deletion is complete, it invalidates (refreshes) the relevant data with a GET request.

• Throughout this process, PostHog is tracking these events for analytics.

Fun stuff right?? As you can also see in the video, the theme is updated and has some color! There will probably be further adjustments there but that’ll be down the line.

Notifications System, Reminder, & Testing Route

The notifications system was another BIG feature of the project. I wanted to create a flexible system that would support multiple notification types (in-app, email, SMS)so a plugin architecture was recommended as the best approach. This allows me to add new notification channels in the future without changing the core notification logic.

I implemented the system with three key components:

1. NotificationManager: The central hub that handles scheduling, displaying, and managing notifications

2. NotificationStore: A Svelte store that maintains the state of active notifications

3. Notification Plugins: Email and SMS plugins that demonstrate the extensibility of the system

Here's the code from the NotificationManager.ts file that shows the plugin architecture:

// Notification Plugin Interface
export interface NotificationPlugin {
    send(notification: Notifications): void;
}

export class NotificationManager {
    private timeouts: Map<string, number> = new Map();
    private plugins: NotificationPlugin[] = [];
    private permission: NotificationPermission = 'default';

    constructor() {
        this.requestPermission();
    }

    public registerPlugin(plugin: NotificationPlugin): void {
        this.plugins.push(plugin);
    }

    // Other code...

    public showNotification(id: string, message: string, type: 'email' | 'sms' | 'in-app'): void {
        // Create notification record
        const notification: Notifications = {
            id,
            message,
            type,
            timestamp: new Date()
        };

        // Add to the notifications store
        notifications.update(n => [...n, notification]);

        // Send to plugins
        this.plugins.forEach(plugin => plugin.send(notification));
    }
}

Another difficult task was implementing the Habit Reminder feature, which allows users to set custom reminders for each habit. This uses the notification system but adds scheduled notifications based on time:

function scheduleReminder() {
    if (!reminderTime) {
        toast.error('Please select a time for the reminder');
        return;
    }

    try {
        // Parse the time input (HH:MM)
        const [hours, minutes] = reminderTime.split(':').map(Number);

        // Calculate when the reminder should trigger
        const now = new Date();
        const reminderDate = new Date();
        reminderDate.setHours(hours, minutes, 0, 0);

        // If the time is earlier today, schedule for tomorrow
        if (reminderDate <= now) {
            reminderDate.setDate(reminderDate.getDate() + 1);
        }

        const delay = reminderDate.getTime() - now.getTime();

        // Schedule the notification
        notificationManager.scheduleNotification(
            `habit-reminder-${props.habitId}`,
            `Time to complete your habit: ${props.habitTitle}`,
            'in-app',
            delay
        );

        // Store reminder in localStorage for persistence
        if (hasLocalStorage) {
            localStorage.setItem(`reminder_${props.habitId}`, JSON.stringify({
                time: reminderTime,
                habitTitle: props.habitTitle
            }));
        }

        reminderEnabled = true;
        toast.success(`Reminder set for ${reminderTime}`);
    } catch (error) {
        console.error('Error scheduling reminder:', error);
        toast.error('Could not schedule reminder');
    }
}

The magic happens in how the system handles timing. When you select 8:00 AM for your "Morning Workout" habit, the system doesn't just blindly schedule it. It first checks if 8:00 AM has already passed today - if it has, it schedules the reminder for tomorrow instead. This prevents the annoying scenario where setting a reminder would trigger it immediately if that time has already passed.

I also made sure that reminders persist between sessions by storing them in localStorage. Each habit gets its own localStorage entry with a unique key: reminder_${habitId}.

The UI for reminders is clean and straightforward:

• If you haven't set a reminder yet, you see a time picker and a "Set Reminder" button

• Once a reminder is set, the UI changes to show the scheduled time and offers a "Remove Reminder" option

This kind of context-aware UI helps keep the interface clean while giving users exactly the controls they need.

I spent some time researching edge cases with reminder systems. What happens if a user sets a reminder for 11:59 PM? What if they set multiple reminders across different habits? Does the system handle timezone changes? These were all important considerations to ensure a robust user experience.

Notification Testing Route

To help debug and demonstrate the notification system, I built a dedicated /notifications testing route. This special route lets me trigger different notification types, test delay timing, and verify that the UI components render correctly.

The testing page provides controls for:

• Sending immediate notifications

• Scheduling delayed notifications (with customizable delay)

• Testing different notification types (in-app, email, SMS)

• Clearing all pending notifications

This testing route has been invaluable during development. Rather than trying to debug notification issues in the middle of the main application flow, I can isolate and test notification functionality directly by just going to my created route.

The best part is that this testing route uses the exact same notification components and manager as the main application, so any fixes or improvements I make here automatically benefit the entire system.

As the application grows, I plan to expand this testing route to include more sophisticated scenarios, like simulating a day's worth of habit reminders compressed into a 1-minute demo, or testing how the system handles overlapping notifications. This dedicated testing environment will ensure that the notification system remains reliable even as new features are added. Before moving on to the PostHog implementation, I added a quick video below showing the notification testing route in action:

PostHog Implementation (Analytics Tracking)

Adding analytics to "Creatures of Habit" was a game-changer for understanding how users interact with the app. I chose PostHog because it's open-source, respects user privacy, and gives me powerful event tracking without complexity.

Implementing PostHog was surprisingly straightforward. I created a dedicated configuration file to centralize all PostHog settings:

import type { PostHogConfig } from 'posthog-js';
import { PUBLIC_POSTHOG_KEY } from '$env/static/public';


console.log('🔍 PostHog: Config file loaded');

export const posthogConfig: Partial<PostHogConfig> = {
    api_host: 'https://us.i.posthog.com',
    capture_pageview: false,
    capture_pageleave: false,
    disable_session_recording: true,
};

export const getPostHogKey = () => {
    if (!PUBLIC_POSTHOG_KEY) {
        console.error('❌ PostHog: API key is not defined');
    }
    return PUBLIC_POSTHOG_KEY;
};

Notice how I've explicitly disabled session recording and automated pageview/pageleave tracking. I wanted complete control over what events get tracked, rather than having a flood of automatic events that might obscure what's truly important. Like I couldn't track a damn thing without movement events rapidly firing lol it was straight overkill.

The initialization happens in my layout file, ensuring PostHog is available throughout the application:

// src/routes/+layout.ts
import posthog from 'posthog-js'
import { browser } from '$app/environment';
import { posthogConfig, getPostHogKey } from '$lib/plugins/PostHog';

export const load = async () => {
    if (browser) {
        posthog.init(getPostHogKey(), posthogConfig);
    }
    return {};
};

I'm using the browser check to ensure PostHog only initializes in client-side contexts, avoiding any server-side rendering issues.

For page navigation tracking, I implemented a custom solution using SvelteKit's afterNavigate hook:

// src/routes/+layout.svelte
if (browser) {
    afterNavigate(() => {
        posthog.capture('$pageview');
    });
}

The real power comes from tracking specific user actions. Now I can see exactly which features users engage with most. For example, when a user completes a habit:

async function completeHabit(habitId: string) {
    try {
        // API call to complete the habit
        const response = await fetch(`/api/habits/${habitId}/complete`, {
            method: 'POST'
        });

        // Process the response...

        // Track the habit completion event
        posthog.capture('habit_completed', {
            habitId,
            difficulty: habitData.difficulty,
            experienceEarned: data.experienceEarned
        });

        toast.success(`Gained ${data.experienceEarned} XP!`);
        // ...
    } catch (error) {
        console.error('Error completing habit:', error);
    }
}

Now I can answer questions like:

• Which habit difficulties do users prefer?

• How many habits do users typically track?

• What times of day do users engage most with the app?

• Which features lead to higher retention?

This data will be invaluable for prioritizing future features. If I see that 80% of users are setting reminders for their habits, I'll know to invest more in expanding the reminder functionality. Conversely, if a feature shows minimal engagement, I can either improve it or deprioritize further development in that area.

The best part is that all of this happens with minimal impact on performance and user privacy. PostHog is lightweight, and I'm only tracking the specific events that provide actionable insights.

🪚 Fixes: Small Changes, Big Impact

Edit Habit Functionality Fix

This issue was racking my brain for a while. The edit functionality was almost working, but the form wasn't properly populated with the existing habit data. Users would click "Edit" on a habit, and the form would appear with blank or incorrect values.

After some debugging, I discovered the issue was in how I was handling the frequency data. The API was returning frequency information in a different structure than what my form component expected.

The fix required adjusting the data mapping in the edit page component:

// src/routes/habits/[id]/edit/+page.svelte
const initialData: HabitData = {
    title: data.habit.title,
    categoryId: data.habit.categoryId ?? undefined,
    description: data.habit.description || '',
    frequency: data.habit.frequencyId ? 'custom' : 'daily',
    customFrequency: {
        days: []
    },
    difficulty: data.habit.difficulty,
    startDate: data.habit.startDate ?? new Date().toISOString()
};

The key insight was realizing that I needed to check for the existence of frequencyId to determine if this was a custom frequency habit. Previously, I was checking a property that sometimes didn't exist, causing the form to render incorrectly.

I also updated the submission handler to use the correct HTTP method and endpoint:

async function handleSubmit(formData: HabitData) {
    const response = await fetch(`/api/habits/${data.habit.id}`, {
        method: 'PUT',
        headers: {
            'Content-Type': 'application/json'
        },
        body: JSON.stringify(formData)
    });

    if (!response.ok) {
        const errorData = await response.json();
        throw new Error(errorData.error);
    }

    await goto('/habits');
}

This might seem like a small change, but it had a massive impact on user experience. Now users can properly edit their habits instead of having to delete and recreate them. I’m still having some issues with the proper date and time showing on the “completed” tasks:

But it’s not breaking anything so that’s something I have noted to work on as a bug fix down the line.

Logout Route POST Action Fix

I had two logout buttons in the app - one in the main navigation and another in the dashboard. Strangely, only one was working correctly. After investigating, I realized I wasn't using SvelteKit's enhance directive on the dashboard logout form.

The fix was simple but crucial:

<form action="/logout" method="POST" use:enhance>
    <Button type="submit" variant="outline" size="sm" class="flex items-center gap-2">
        <LogOut class="h-4 w-4" />
        Logout
    </Button>
</form>

The enhance directive is crucial here - it tells SvelteKit to handle the form submission using client-side JavaScript when possible, rather than triggering a full page reload. Without it, the form was submitted traditionally, which disrupted the expected application flow.

I also removed the secondary Logout CTA cause it was redundant. This fix ensures that the logout button works consistently and provides a smooth user experience.

Updated Signup Route's CTA with isSubmitting for Better UX

One of my pet peeves is form buttons that don't provide feedback. When you click "Sign Up" on most websites, you're left wondering if anything is happening, especially if there's network latency.

I solved this by adding a loading state to the signup form's button:

<Button on:click={nextStep} disabled={isSubmitting}>
    {#if isSubmitting}
        <div class="mr-2 h-4 w-4 animate-spin rounded-full border-2 border-current border-t-transparent"></div>
        {currentStep === totalSteps ? 'Creating Account...' : 'Processing...'}
    {:else}
        {currentStep === totalSteps ? 'Create Account' : 'Next'}
    {/if}
</Button>

This provides two crucial UX improvements:

1. Visual feedback via the spinning loader

2. Text feedback that changes based on the current step

Additionally, the button gets disabled during submission, preventing accidental double-clicks that could lead to duplicate accounts or other errors.

It's a small enhancement that dramatically improves perceived performance and reduces user anxiety during the critical signup process.

Implemented Toast in the App's Notification System

To provide non-intrusive feedback throughout the app, I integrated Svelte Sonner for toast notifications. These small, temporary messages appear at the top of the screen to confirm actions or display errors without disrupting the user experience.

CodeRabbit (Temporary; Experimenting with it)

I don’t know about this one. Feels like a bit of overkill and has yet to point out anything that was a critical error. However, I’m going to give it some more time. I think this would be a slippery slope though if it DOES work. I can’t lean on AI too heavily or It’ll erode my basic debugging skills I’m already lacking a bit of lol. Nonetheless, I AM finding it helpful for catching small issues and suggesting improvements. One particularly helpful aspect has been its suggestions around TypeScript typing. It's helped me make my type definitions more precise and catch potential null reference errors.

All that said, I’ll continue treating it as an experiment for now and evaluate its usefulness as the project progresses.

Looking Ahead

While I've made significant progress, there's still a lot to do:

1. Stats & XP System Enhancement: The stats need to actually affect things in the app and it also needs to be adjusted to have a min and max at character creation. Right now it’s just character lore at this point.

2. Homepage Redesign: I need a real homepage that demonstrates the unique RPG-habit connection with interactive elements and clear CTAs for engagement and sign-ups.

3. Quests and Campaigns: What’s an RPG app without quests?! This system has yet to be prototyped so I’d need to do some research.

4. Dashboard and UI Improvements: Enhance the user interfaces with character-updated status displays, streak indicators, and progress charts to improve the overall experience.

5. Progressive Achievements: Tiered achievement system with visual badges, titles, and an achievement gallery to provide additional motivation through accomplishments.

The journey of building this app has been pretty damn rewarding, even more so than the finance tracking app. Mainly based on the pure scope and how much I've learned thus far. It’s also shown me that there is still a shit ton to learn about these types of apps and how to properly build them. Trying to turn a habit-tracking app and transforming it into a dope RPG experience has stressed me out 😅 but also has pushed me in certain areas. Stay tuned for what’s next on deck 🤘🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Boy, has this been a busy year so far, and it’s not even a month old. Since my last article, I’ve been putting in a ton of time on this project. As soon as the new year hit, I made it a goal to work on this or a different project every day to see how long I could keep my coding streak. I’m 24 days in now, and there is no sign of breaking, but then again, it’s been less than a month 😅.

The main accomplishment with this is to build up my consistency. I recently got a new promotion working on a different team (which also started this year) so I’ve been trying to skill up on my day-to-day consistency. Like many others, I assume the wild nature of how life in the US has been unfolding has been…..distracting, to say the least. But with that aside, I’m aiming for 2025 to be my year of consistency. I’m talking like BIG CONSISTENT energy, where my entire GitHub contribution graph for this year is fully green and I have at least one solid project in production, that project being Creatures of Habit.

State of the App and Roadmap

After writing up my authentication, I made a roadmap and plan on what I needed to accomplish for an MVP. Below is the rough plan and I’m only going to post the sub-tasks of Phases 1 and 2. Phases 3-5 will just show the feature/goal for that sprint since it’ll be a while until I start them and didn’t want to bloat this article:

Phase 1: Foundation & Authentication (4-6 weeks)

1. User System Setup

   • Implement secure user registration and login using Lucia authentication library

     • Integrate with database for user data storage

     • Implement password hashing and security measures

   • Design and implement intuitive profile creation flow

     • Multi-step wizard for gathering user information

     • Profile completeness indicator

   • Develop basic settings page with account management options

     • Password change functionality

     • Notification preferences

     • Privacy settings

   • Implement optional email verification system

     • Automated verification email sending

     • Secure verification link generation and processing

2. Character Creation

   • Design and implement fantasy race selection system

     • Create detailed descriptions and visual representations for each race

     • Implement unique stat bonuses and abilities for each race

     • Develop race-specific storylines and background options

   • Develop custom avatar creation system

     • Design modular character parts (hair, eyes, body types, etc.)

     • Implement color customization for various features

     • Create randomization option for quick character generation

   • Design and implement initial class or path choice system

     • Create detailed class descriptions and abilities

     • Implement class-specific starting equipment and skills

     • Develop class change or multi-class options for future progression

   • Develop starting stats allocation system

     • Create balanced stat distribution options

     • Implement stat impact explanations and tooltips

     • Develop reallocation or respec options for future use

   • Implement character naming system

     • Create name generation options (random, themed, custom)

     • Implement name uniqueness checks

     • Develop naming conventions and filters

Phase 2: Core Habit System (6-8 weeks)

1. Habit Management

   • Implement CRUD operations for habits

     • Design intuitive habit creation interface

     • Develop habit editing and updating functionality

     • Implement soft and hard deletion options

     • Add a visual when selecting a custom frequency so the user can see the days on the task

   • Design and implement habit categories and types

     • Create pre-defined categories (health, productivity, etc.)

     • Implement custom category creation

     • Develop habit type system (daily, weekly, one-time)

   • Develop frequency settings for habits

     • Implement daily, weekly, and custom recurrence options

     • Develop reminder system integrated with frequency settings

   • Implement difficulty levels for habits

     • Create balanced difficulty scale (easy, medium, hard, etc.)

     • Develop adaptive difficulty system based on user performance

     • Implement difficulty-based rewards and experience points

   • Design and implement reward calculations

     • Create algorithm for calculating rewards based on difficulty and consistency

     • Implement bonus rewards for streaks and milestones

     • Develop penalty system for missed habits

2. Daily System

   • Design and implement daily quests and tasks view

     • Create visually appealing and intuitive daily dashboard

     • Implement task prioritization and sorting options

     • Develop quick-add functionality for impromptu tasks

   • Implement check-in system

     • Design user-friendly check-in interface

     • Develop partial completion options for habits

     • Implement undo or correction functionality for accidental check-ins

   • Develop streak tracking system

     • Implement streak calculation algorithm

     • Create visual representations of streaks (flames, chains, etc.)

     • Develop streak recovery options (grace periods, streak freezes)

   • Implement daily reset logic

     • Develop time zone aware reset system

     • Implement rollover options for uncompleted tasks

     • Create daily summary and reflection prompts

   • Design and implement progress indicators

     • Create visual progress bars for habits and overall daily goals

     • Implement milestone celebrations and achievements

     • Develop long-term progress tracking and visualization

Phase 3: RPG Elements (6-8 weeks)

Phase 4: UI/UX Implementation (4-6 weeks)

Phase 5: Enhanced Features (6-8 weeks)

As you can see, I still have PLENTY to get done before this app is considered a working alpha. Anything crossed out has been finished so you can see my current state for this app. But I’m already very proud of the work I've put in thus far. This is the most consistent I’ve been with coding since my Lambda School days, and my current streak surpassed all streaks set when I was enrolled in 2019.

Some of the biggest challenges with what I’ve finished though would have to relate to the user system and character creation setup. I leaned HEAVILY on online resources and examples from other apps but got the job done. One thing that’s constantly tripping me up is the type system. Working with types in Typescript vs types in PHP throws me for a loop every time. They are pretty different in terms of how types are implemented and while Typescript is more strict and unforgiving, PHP is a bit looser, has type juggling, and is written differently for the most part (EX: Typescript uses type interfaces and PHP only uses them in certain contexts).

This brings me back to a hurdle I’ve mentioned in my past posts: the annoying action of context-switching. I’d love to focus on Typescript and Svelte for work and my personal projects, but the world isn’t my oyster, so I gotta do what I gotta do to pay the bills 💸.

For example, here is how I have the CreatureStats type interface set up in TS:

export interface CreatureStats {
    strength: number;
    dexterity: number;
    constitution: number;
    intelligence: number;
    wisdom: number;
    charisma: number;
}

export interface RegistrationData {
    email: string;
    username: string;
    password: string;
    confirmPassword: string;
    age: number;
    creature: {
        name: string;
        class: CreatureClassType;
        race: CreatureRaceType;
        stats: CreatureStats;
        background?: string;
    };
    general: string;
}

You can see the stats being created in its own interface and being referenced in the RegistrationData interface. Below, it’s being set in my RegistrationWizard.svelte component with it’s default values:

    let formData = $state<RegistrationData>({
        email: '',
        username: '',
        password: '',
        confirmPassword: '',
        age: 0,
        creature: {
            name: '',
            class: CreatureClass.WARRIOR,
            race: CreatureRace.HUMAN,
            stats: {
                strength: 10,
                dexterity: 10,
                constitution: 10,
                intelligence: 10,
                wisdom: 10,
                charisma: 10
            },
            background: undefined
        },
        general: ''
    });

Whereas, this is how it would look in PHP:

<?php

interface CreatureStats {
    public function getStrength(): int;
    public function getDexterity(): int;
    public function getConstitution(): int;
    public function getIntelligence(): int;
    public function getWisdom(): int;
    public function getCharisma(): int;
}

<?php

$creatureStats = [
    'strength' => 10,
    'dexterity' => 8,
    'constitution' => 12,
    'intelligence' => 14,
    'wisdom' => 10,
    'charisma' => 6
];

$registrationData = new RegistrationData();
$registrationData->email = "{enter email}";
$registrationData->creature = [
    'name' => '{Creature Name}',
    'class' => CreatureClass::ARCHER,
    'race' => CreatureRace::ELF,
    'stats' => $creatureStats
];

The key differences between TS and PHP when it comes to types:

• Type Safety: TypeScript provides compile-time type checking, while PHP relies on runtime checks and optional type hints.

• Advanced Types: TypeScript supports generics, unions, intersections, and more, which PHP does not natively support.

• Interfaces: TypeScript interfaces are purely structural, while PHP interfaces are more rigid and require explicit implementation.

However, the daily work and consistency are helping alleviate the struggle with context switching, so I just have to keep up the hustle.

Oh, You Want a Lil Preview???

Instead of showing every little thing I’ve done via code snippets, I implore you to check out the Github repo and clone/fork it to try it out locally. It’s nothing pretty as of yet but a lot of the main features are ready to use/test out. In the video below, I’ll go through creating a new user, character, and habit. This should show the persistence of the user log-in and state, basic CRUD, and a look at the user dashboard and creature dashboard.

I tend to ramble so I used all 5 min of the loom video limit for free accounts lol. But I do touch on everything I said I would. Some other features work like, “Change Password” and" “Edit Habit” but I was running out of time so they aren’t shown in the demo

EOD

✌🏾 that wraps up my check-in. Hopefully, some interested people out there want to check out the app locally and play around. I’m always open to feedback so if you have any suggestions or critiques, submit an issue or contribute and make a pull request! I’m planning on doing another check-in within the next month or 2 so be on the lookout for my next update!

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

What’s up folks, been a minute since my last post. As everyone and their mother knows the last couple of months have been pretty hectic in terms of things going on in the world. All the while, I’ve been head down on making moves within my company and the efforts have paid off. My last project (https://leo-ledger.onrender.com/) seems to still be living, due to Render changing its free tier limits (although, it still takes about 60 seconds for the server to boot back up 🫠). No additional work has been put into it and I’m now thinking that I will most likely leave the project as is. This is due to the fact that I don’t plan on using HTMX in many of my future projects. I enjoyed seeing its capability when it comes to working closely with Python, but 9/10, I’m opting for Svelte w/Typescript to handle my front end.

I’ve become comfortable with the pair and depending on the type of project I’m doing, I will either choose Django to handle my backend or stick with Typescript, an ORM, and DB tool. I recently started a new project with a scope bigger than I’ve handled before 😅, but I wanted to challenge myself with one main objective, to strengthen my understanding of the scope of different types of applications. I work for a company that builds and maintains websites for car dealerships and I’ve gotten a great sense of the workflow of a company this size and our client’s needs/expectations for their customers. As mentioned earlier, My last project was a Finance tracker and the scope of that project is much different than what I do for a paycheck. That leads me to my new project and the theme of this article.

🥁🥁🥁Drum Roll🥁🥁🥁

My next project is a RPG Habit Tracker App! Nothing super original about this idea but the scope of this type of app is much different than my finance tracker and what I do at my job. This forces me to reach for new tools that will better suit the project’s functionality which for me, is what keeps me excited about building things. I’ve probably mentioned it in a previous article but my tendency to be a “Jack of All Languages” sometimes hinders me from really understanding a specific language if I don’t do enough work with it. It’s come to bite me in the ass a couple of times as well but I’m learning to manage my context switching a bit better. One thing I need to do is practice more on code wars and get OOP fundamentals down to a T as well as just thinking a bit more pragmatically. But enough rambling, we’re here to talk about some pretty dope things I learned when I started to work on authentication for my new app. My repo is pubic for the moment but i might move it back to private. Get a gander while you still can → https://github.com/kdleonard93/creatures-of-habit.

So Long Lucia

When deciding on the tech stack I was going to use for this project, the Sveltekit scaffolding process showed Lucia and I’ve heard of the tool in the past as a great choice for setting up Auth within a Sveltekit app. But when I got my project all set. I noticed there were no Lucia references in the auth.ts file. After some searching on the net, I discovered that the maintainer was no longer working or using Lucia himself and explained that it just wasn’t working in its current state. They made an announcement stating that it would be deprecated in March 2025. But what they are doing to circumvent the hole it’s leaving in the community, is turning that repo into a learning source on implementing auth from scratch on your own. Now I'm sure that sounds cumbersome and I thought the same exact thing, but it really wasn’t that bad and I ended up learning a bit about general guidelines related to implementing auth on web applications.

Okay Cool, You Learned About Sessions……Want a Cookie?!?!

Hopefully, the section title wasn’t too corny 😏, but this is where I yap about how I appreciate what that maintainer did. If they never made documentation on how to convert from Lucia and build auth from scratch on my own, I might have switched up my stack a bit and used Drizzle with Supabase instead of Drizzle with Turso. The Lucia docs are straightforward and concise when it comes to examples of setting up sessions and cookies, providing documentation links for related references like, encoding schemes, the Crypto: randomUUID() method, and the SHA-256 hash function to name a few.

Without getting into much of the nitty gritty (much of which i’m still wrapping my head around), the main advantage with digging deep and writing these from scratch is I can apply this knowledge to other projects that don’t necessarily use the same stack. It also helps me understand the nuances of authentication under the hood so I’m better equipped to be a helping hand to folks that aren’t privy to building auth.

Let's dive into the nuts and bolts of implementing authentication from scratch. I'll break down my auth.ts file to show you how surprisingly manageable this process can be (even though some concepts are still a. bit fuzzy to me).

The Building Blocks

First up, we have some core functionality for handling sessions:

1. Session Token Generation: We create a secure random token using crypto.getRandomValues() and encode it in base32. This gives us a unique identifier for each user session.

export function generateSessionToken() {
    const bytes = crypto.getRandomValues(new Uint8Array(20));
    return encodeBase32LowerCase(bytes);
}

2. Session Creation: When a user logs in, we create a new session by:

   • Hashing the token using SHA-256 (for secure storage)

   • Setting an expiration date (30 days from creation)

   • Storing it in our database with the user's ID

export async function createSession(token: string, userId: string) {
    const sessionId = encodeHexLowerCase(sha256(new TextEncoder().encode(token)));
    const session: table.Session = {
        id: sessionId,
        userId,
        expiresAt: new Date(Date.now() + DAY_IN_MS * 30)
    };
    await db.insert(table.session).values(session);
    return session;
}

The cool thing about this approach is that we never store the raw session token in our database, just the hashed version. This adds an extra layer of security in case our database ever gets compromised.

Session Management & Validation

The real magic happens in the validateSessionToken function. Here's what it does:

• Checks if the session exists

• Verifies it hasn't expired

• Automatically renews sessions that are close to expiring (15 days out)

• Returns the user's data if everything checks out

export async function validateSessionToken(token: string) {
    const sessionId = encodeHexLowerCase(sha256(new TextEncoder().encode(token)));
    const [result] = await db
        .select({
            // Adjust user table here to tweak returned data
            user: { id: table.user.id, username: table.user.username },
            session: table.session
        })
        .from(table.session)
        .innerJoin(table.user, eq(table.session.userId, table.user.id))
        .where(eq(table.session.id, sessionId));

    if (!result) {
        return { session: null, user: null };
    }
    const { session, user } = result;

    // Check if session is expired
    const sessionExpired = Date.now() >= session.expiresAt.getTime();
    if (sessionExpired) {
        await db.delete(table.session).where(eq(table.session.id, session.id));
        return { session: null, user: null };
    }
    // Renew session if close to expiration
    const renewSession = Date.now() >= session.expiresAt.getTime() - DAY_IN_MS * 15;
    if (renewSession) {
        session.expiresAt = new Date(Date.now() + DAY_IN_MS * 15);
        await db
            .update(table.session)
            .set({ expiresAt: session.expiresAt })
            .where(eq(table.session.id, session.id));
    }

    return { session, user };
}

I also implemented automatic session renewal. If a user's session is within 15 days of expiring, it gets extended in the background. This creates a smoother user experience to prevent kicking users off the app when their current session ends 🤘🏾.

Cookie Management

The final piece of the puzzle is cookie handling. We set two main functions:

setSessionTokenCookie(event, token, expiresAt)
deleteSessionTokenCookie(event)

These handle the grits of cookie management with some important security settings:

• httpOnly: true prevents JavaScript access to the cookie

• sameSite: "lax" provides a good balance between security and usability

• Proper expiration handling ensures cookies clean up after themselves

Why This Matters

Building this from scratch instead of using a library like Lucia taught me a ton about web security. It's not just about storing a user's login state – it's about:

• Secure token generation and storage

• Protection against session hijacking

• Proper cookie security settings

• Graceful session expiration handling

While it might seem daunting at first, breaking down authentication into these components makes it much more approachable. Plus, as I previously mentioned, I can now adapt this knowledge to any framework or project I work on in the future.

The full file is below for reference:

import type { RequestEvent } from '@sveltejs/kit';
import { eq } from 'drizzle-orm';
import { sha256 } from '@oslojs/crypto/sha2';
import { encodeBase32LowerCase, encodeHexLowerCase } from '@oslojs/encoding';
import { db } from '$lib/server/db';
import * as table from '$lib/server/db/schema';

const DAY_IN_MS = 1000 * 60 * 60 * 24;

export const sessionCookieName = 'auth-session';

export function generateSessionToken() {
    const bytes = crypto.getRandomValues(new Uint8Array(20));
    const token = encodeBase32LowerCase(bytes);
    return token;
}

export async function createSession(token: string, userId: string) {
    const sessionId = encodeHexLowerCase(sha256(new TextEncoder().encode(token)));
    const session: table.Session = {
        id: sessionId,
        userId,
        expiresAt: new Date(Date.now() + DAY_IN_MS * 30)
    };
    await db.insert(table.session).values(session);
    return session;
}

export async function validateSessionToken(token: string) {
    const sessionId = encodeHexLowerCase(sha256(new TextEncoder().encode(token)));
    const [result] = await db
        .select({
            // Adjust user table here to tweak returned data
            user: { id: table.user.id, username: table.user.username },
            session: table.session
        })
        .from(table.session)
        .innerJoin(table.user, eq(table.session.userId, table.user.id))
        .where(eq(table.session.id, sessionId));

    if (!result) {
        return { session: null, user: null };
    }
    const { session, user } = result;

    // Check if session is expired
    const sessionExpired = Date.now() >= session.expiresAt.getTime();
    if (sessionExpired) {
        await db.delete(table.session).where(eq(table.session.id, session.id));
        return { session: null, user: null };
    }
    // Renew session if close to expiration
    const renewSession = Date.now() >= session.expiresAt.getTime() - DAY_IN_MS * 15;
    if (renewSession) {
        session.expiresAt = new Date(Date.now() - DAY_IN_MS * 15);
        await db
            .update(table.session)
            .set({ expiresAt: session.expiresAt })
            .where(eq(table.session.id, session.id));
    }

    return { session, user };
}

export type SessionValidationResult = Awaited<ReturnType<typeof validateSessionToken>>;

export async function invalidateSession(sessionId: string): Promise<void> {
    await db.delete(table.session).where(eq(table.session.id, sessionId));
}

export function setSessionTokenCookie(event: RequestEvent, token: string, expiresAt: Date): void {
    event.cookies.set(sessionCookieName, token, {
        httpOnly: true,
        sameSite: "lax",
        expires: expiresAt,
        path: '/'
    });
}

export function deleteSessionTokenCookie(event: RequestEvent): void {
    event.cookies.delete(sessionCookieName, {
        httpOnly: true,
        sameSite: "lax",
        maxAge: 0,
        path: '/'
    });
}

If anyone is looking for a deeper dive into the docs, I’ve added a couple of references below:

• https://lucia-auth.com/ (resources on implementing authentication with JavaScript and TypeScript)

• https://thecopenhagenbook.com/ (a general guideline on implementing auth in web applications)

“Creatures of Habit” Status

My newest project, Creatures of Habit, is underway and off to a good start. The reason behind waiting to create an RPG-specific habit-tracking app is:

1. I love RPGs….plain and simple 😂.

2. There are a few habit trackers out there that gamifies the tasks but none of them seemed to work exactly how I pictured it would work.

My stack for this project is Sveltekit w/Typescript, Shadcn Svelte + Tailwind CSS, Drizzle ORM w/ SQLite, and authentication based on this guide from the Lucia maintainer. My goal, while hefty, is to create the perfect habit-tracking app for me and me only…if other people like it then so be it lol. But in all seriousness, my MVP (Minimum Viable Product) for this project is to get a working web app that actually functions like a storyboard/tabletop RPG. None of the other apps focus on the hero (or creature in my app’s case) enough. There are always a few stats given but none really felt like an RPG, just these shell RPGs that feel like grind fests or they turned into more of a subscription model for extra features and I totally get the latter if it’s a small team and they want to actually make money from the work they did. Habitica is a great example of an app that I want to make an improved version of. It’s got most of the features I’d want in an RPG-style habit tracker but there are also a few things I think it’s missing. Here is a little screenshot of the Dailies tab:

One main feature I’d like to change is the quest system. It seems more akin to chores than actual quests. The main reason is because there is no story behind each quest. My idea is to treat them as recurring quests that get harder and harder each run-through, kind of like a roguelike progression with dungeons. Each dungeon has a boss but before you get to that boss level, you have to complete the objectives on each preceding level. Once the dungeon is cleared, there is a new tier you can do that will offer more exp and loot. That’s just one thing I’d change amongst a few others but overall, this will be an interesting journey to completion (or at least a working alpha). I made a roadmap in Notion and you can find that here → https://www.notion.so/Creatures-of-Habit-Roadmap-135ab7433e8e80d6a175c7de10bdb631?pvs=4

Day 30-33 of “100 Days of Python”

Moving like molasses with this course 😅, but still moving nonetheless. The 4 days that were completed covered:

1. Errors, Exception, & JSON data

2. Flash Card Project

3. Email Sending with the smtplib & datetime modules.

4. Learning about API Endpoints w/ ISS Overhead Notifier project

The only new(ish) things covered within these 4 days were Errors, Exceptions, and using API Endpoints + Parameters. I won’t go into detail on these areas since this article is focused on Auth and my new project but you can find the completed code for each day on my 100-Days-Of-Python repo.

Conclusion

So that’s a wrap on this joint. There are lots of intriguing milestones to hit over the next year and I’m starting to settle in with what works for me in terms of my productivity. Tons of things learned in 2024 and I’m excited to get 2025 started on the right foot. I plan to continue posting article updates for the project but will also start smaller Python-based projects as well to not tire myself out on building Creature of Habit. The Python-specific projects are going to revolve around scripting and making things to automate my daily life + scripts for autonomous investing, specifically using the various APIs in the blockchain space. Until next time, folks ✌🏾.

If you want to keep up with my work or want to connect as peers, check out my social links below and give me a follow!

• 🦋 Bluesky

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

I’m combining these 2 days (and will probably group these up moving forward) and the Day 28 project was interesting but pretty boring 🥱. The objective was to create a Pomodoro app, which is essentially a focus time/break stopwatch. The app itself is very useful but there are of course a ton of apps similar to this that would be more beneficial and are built completely differently, but nonetheless, it was good practice.
The code can be found here → https://github.com/kdleonard93/100-Days-Of-Code_Python/tree/main/day-28 and give the program a try yourself. There weren’t any new and noteworthy concepts covered on this day so I won’t bore you with rambling about it.

Peak Tkinter

Day 29 however, was a very interesting project. The password manager we created was supposed to have 3 main functions:

• Clean UI and alined entry fields

• The “Generate Password” button generated a strong random password and added it into the corresponding field + copied it to your clipboard.

• The “Add” button adds it to a text file and starts a new line after.

Pretty straightforward goals but I also wanted to add another button to clean up file when I didn’t want it anymore. So I decided to add 1 additional function to this project that isn't in the module:

• I added a “Delete” button that deletes the file.

One thing she notes here is that people are more inclined to store passwords on their local machine since that is the safer option and for the most part, I agree. However, she just tosses the password into a textfile. Now, I’m sure there are better methods to store passwords locally, but the one thing I added to her implementation was to make text file hidden to at least give me the illusion of storing passwords safely on my machine 😂. I enjoyed the password manager project and picked up a few tips along the way.

Some Things I Learned

There were two new functions from Tkinter that I hadn’t used before and picked up here. The tk.insert() and tk.delete() functions were used for my “Generate Password” and “Delete Text File” buttons, respectively. Nothing super unique about how they work but here is a quick overview and let’s say our entry in question is email:

• email.insert(index, "Text"): Takes 2 arguments, the first is the index of entry you choose and the second argument is the text you’d like to insert. Pretty damn simple

• email.delete(start_index, end_index): Takes 2 arguments, being the start and the end indexes of what you want to delete. 9/10, you’d write something like: email.delete(0, END) to delete the entire entry field.

The second main takeaway from this project was the use cases for the paperclip library. Now I didn’t actually use that library for this project since Tkinter has its own clipboard functions, but, I do see myself using this library on future projects that need some sort of auto copy to clipboard. Bookmarked 🤘🏾.

If you wanna give this little project a spin, you can clone/fork it here → https://github.com/kdleonard93/100-Days-Of-Code_Python/tree/main/day-29

Here’s a lil’ demo:

EOD

That pretty much sums up these 2 days. I mentioned this in a previous post but I’ve been trying to figure out the best and most affordable way to gain some Kubernetes skills. Was informed by my company that they “didn’t have the budget” for the certificate training. Which to me is pretty shocking as the certificate is only $400. I’d understand not being able to reimburse tuition or anything else at a similar scale but $400??

But enough of my ranting, I still plan to make moves in the DevOps field and gain a deeper knowledge of Kubernetes and Docker. I’m finding that I like DevOps more and more as time passes. Either that or I’m starting to hate designing pages more and more as the day goes on lol. I’m garbage at styling and would truly be happier if I never have to do it again.

If you want to keep up with my writing or want to connect as peers, check out my social links below and give me a follow!

• 𝕏 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

I skipped it.....fight me about it 😄. But for real, skipped writing up and pushing a PR for day 26 cause it wasn't anything new and felt like a waste of time. I was also still in a bad headspace (quick context at the end of this post), so I kept it moving. That leads us to Day 27!

Understanding *args and **kwargs

For day 27, the focus was on *args and **kwargs. *args and **kwargs are special operators that allow functions to accept an arbitrary number of arguments and keyword arguments respectively. Below is a quick definition of both and how they can be useful:

• *args allows you to pass any number of positional arguments to a function. This is handy when you want to write functions that can handle varying amounts of input data.

• **kwargs lets you handle named arguments that you have not explicitly defined in advance. This is great for working with functions where you might have a variety of configuration options.

Pros:

• Flexibility: Both *args and **kwargs provide flexibility in function calls, allowing for more general and adaptable code.

• Convenience: They can make initializing objects and calling functions cleaner and more intuitive. Let's say, for example, when dealing with a complex set of parameters.

Cons:

• Readability: Functions using *args and **kwargs can be less explicit, which might lead to code that is harder to understand.

• Debugging: It can be more challenging to debug issues as the source of incorrect values can be obscured.

A few code examples for my visual folks

Here’s how you might use these in your own Python scripts:

Basic Usage of *args

def my_function(*args):
    for arg in args:
        print(arg)

my_function('Hello', 'World', 123, true)

This function will accept any number of arguments and print each one. So if i wanted to pass 4 arguments, I'd just need to call my_function('Hello', 'World', 123, True) . With the 4th argument being a boolean.

Basic Usage of **kwargs

def my_function(**kwargs):
    for key, value in kwargs.items():
        print(f"{key} = {value}")

my_function(name='Alice', age=25)

This function prints out key-value pairs, accepting any number of named arguments. The same thing goes for **kwargs when it comes to adding boolean values. It gets a bit trickier though but hopefully the updated example helps:

def my_function(**kwargs):
    # Print all keyword arguments
    for key, value in kwargs.items():
        print(f"{key} = {value}")

    # Check if debug mode is enabled
    if kwargs.get("debug", False):  # Explicitly use default value for clarity
        print("Debug mode is enabled.")
    else:
        print("Debug mode is not enabled.")

    # Check if logging is on or off
    logging_status = 'on' if kwargs.get('logging', False) else 'off'
    print(f"Logging is {logging_status}.")

my_function(name='Alice', age=25, debug=True, logging=False)

The expected output of the above code is:

name = Alice
age = 25
debug = True
logging = False
Debug mode is enabled.
Logging is off.

How Tkinter heavily uses args and *kwargs

Tkinter uses *args and **kwargs extensively to make it flexible when creating widgets with varying configurations.

Widget Example

Here’s a Tkinter example from the day's project how *args and **kwargs are useful for creating UI elements with different configurations:

from tkinter import *


def button_clicked():
    print("I got clicked")
    new_text = input.get()
    my_label.config(text=new_text)


window = Tk()
window.title("My First GUI Program")
window.minsize(width=500, height=300)
window.config(padx=100, pady=200)

# Label
my_label = Label(text="I Am a Label", font=("Arial", 24, "bold"))
my_label.config(text="New Text")
my_label.grid(column=0, row=0)
my_label.config(padx=50, pady=50)

# Button
button = Button(text="Click Me", command=button_clicked)
button.grid(column=1, row=1)

new_button = Button(text="New Button")
new_button.grid(column=2, row=0)

# Entry
input = Entry(width=10)
print(input.get())
input.grid(column=3, row=2)


window.mainloop()

I'll run through a quick explanation of each important section.

Import Tkinter

pythonCopy codefrom tkinter import *

This line imports all classes, functions, and variables from the Tkinter module. It allows the script to access Tkinter's GUI components without prefixing them with tkinter. .

Define Button Click Function

def button_clicked():
    print("I got clicked")
    new_text = input.get()
    my_label.config(text=new_text)

This function button_clicked is called when the GUI's button is clicked. It performs a couple actions:

1. Prints "I got clicked" to the console.

2. It retrieves text from an entry widget (input), and sets this text as the new label for my_label using config().

Set the Main Window

window = Tk()
window.title("My First GUI Program")
window.minsize(width=500, height=300)
window.config(padx=100, pady=200)

These lines set up the main window of the application:

• Tk() creates the main window.

• title() sets the window's title.

• minsize() specifies the minimum size of the window.

• config() adds padding around the inside of the window (100 pixels on the sides, 200 pixels on the top and bottom).

Create Label

my_label = Label(text="I Am a Label", font=("Arial", 24, "bold"))
my_label.config(text="New Text")
my_label.grid(column=0, row=0)
my_label.config(padx=50, pady=50)

This section creates a label widget:

• Label() creates a label with initial text "I Am a Label" and specifies the font.

• The label text is immediately changed to "New Text" with config().

• grid() places the label in the grid layout (at column 0, row 0).

• Additional padding is added around the label.

Create Buttons

button = Button(text="Click Me", command=button_clicked)
button.grid(column=1, row=1)

new_button = Button(text="New Button")
new_button.grid(column=2, row=0)

This code creates two buttons:

• The first button, when clicked, triggers button_clicked().

• The buttons are placed using grid(); the first button at column 1, row 1, and the second button at column 2, row 0.

• The second button is just filler. There is no command attached to it.

Create an Entry Widget

input = Entry(width=10)
print(input.get())
input.grid(column=3, row=2)

• Entry() creates an entry widget allowing users to input text.

• input.get() is used to retrieve the current text in the entry widget, which is empty initially and its result ('') is printed.

• grid() positions the entry widget in the grid.

Start the GUI

window.mainloop()

This line starts the Tkinter event loop, which is necessary to keep the window displaying and responding to user inputs.

That's it, a pretty vanilla GUI created with just Tkinter 🙂.

Conclusion

Using *args and **kwargs can significantly increase the flexibility and reusability of your Python code, making it easier to handle functions with a variable number of parameters. When paired with Tkinter, these operators allow you to create more dynamic and configurable GUIs without committing to a fixed number of parameters in your functions. While they offer great advantages, no need to go crazy and use them everywhere lol. Use it if it helps maintain code clarity and simplicity.

I still have plans to add authentication to my FanFlix project and have been making some adjustments behind the scenes in how I want to tackle my Finance tracker app 🙃. I can never make up my mind

Hiatus Context for whoever cares

Emerging from the shadows of sadness

My life is defined by shake-ups, I'm almost certain of it now. Needed to take yet another break away from leveling up and Python projects because of a few things (that I won't go in-depth over):
1. Long-term relationship was getting rocky and ultimately ended last month.
2. Had to make a quick move recently out of our shared home causing me to drop a ton of money in a very short time.
3. And worst of all, a couple of weeks ago, lost a relative that I was extremely close to.

It's hard to keep my focus on leveling up when my world and the general world is in chaos. My heart aches for myself and my family, but it also aches for the innocent lives in the DR Congo, Haiti, Sudan, and Gaza. It's really grim times out here and I've had to shift focus on family and friends. At the end of the day, time is the only thing we can't get back, so for the people I care about, I need to dedicate more time to just having fun and experiencing joy with them. Who knows, anything unexpected can happen just like it did for my fam.

If you want to keep up with my writing or want to connect as peers, check out my social links below and give me a follow!

• 𝕏 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Flashing back to my previous post, I mentioned I was working on a "Movie List" project using Django, Svelte, and TypeScript. Typescript was an addition to this project as I've been wanting to learn it for some time now to have better type safety in my projects helping me catch errors early in my text editor instead of in the browser. I feel it also encourages better coding practices in general, so I wanted to embrace and use it moving forward instead of just using JS. I'd like to coin the DUST stack (Danjgo UI Svelte Typescript) for the project. I was also thinking of other stack names like CESN (pronounced season) which would be CockroachDB, Express, Svelte, and Node but let's not go down a tech-stack acronym rabbit hole lol.

The project, at first glance, appears straightforward but is quite intricate under the hood. My primary learning curve was working with Django for the first time. Although I've done some setup work with Django and Flask before, this is my first complete project with a functioning database. Django's handling of the heavy lifting, like WSGI and ORM setup, allowed me to focus more on the documentation, styling, and additional functionalities.

Frontend Finesse

Svelte is increasingly becoming my preferred frontend framework. It's much easier for me to grasp core concepts in Svelte compared to React. Having recently used Vue at work, I'd rank my framework preferences as Svelte, Vue, Qwik, and then React. I've never used Qwik, but that's a testament to my aversion to React (big feels 😤). But enough of my rambling, let us get into what I used in full and what I learned along the way.

SkeletonUI

I initiated the project using Sveltekit and Skeleton as the UI library. Skeleton, being tightly integrated with Svelte, is like a component library for Tailwind CSS but specifically tailored for Svelte and Sveltekit. It includes components, stores, and actions. The theme generator on their site is a standout feature, allowing users to experiment with pre-designed themes or create their own. This is especially helpful for those, like myself, who aren't inherently skilled in design. I experimented with several themes before settling on a pre-designed one to adhere to best color practice standards.
Unlike my recent Dev Portfolio update, which was just working with basic Svelte components, I dove deeper into Sveltekit's core concepts such as Filesystem-Based Routing, Loading Data, and Form Actions.

Routing

This routing system is CLUTCH for readability and file structure. Each route of the app, let's say for example: src/routes/about, is the actual page URL and in this instance, the URL would be http://localhost:5173/about. Now within the project directory, the /about/ route is a folder that would contain the actual svelte files for the page.

+page

For a quick definition: A +page.svelte component defines a page of your app. By default, pages are rendered both on the server (SSR) for the initial request and in the browser (CSR) for subsequent navigation. According to the docs, often times a +page.js/ts will be added in the same folder to load actual data for the page to render.

Loading Data

The docs explained this very clearly so I'll just echo what they said for the most part. A +page.svelte file can have a sibling +page.js that exports a load function, the return value of which is available to the page via the data prop. For example in my case, below I've added what my load function looks is:

export function load({ params }) {
  return {
    id: params.id,
  };
}

Essentially, this function is designed to run when a specific film's route is accessed. The {params} object is passed to the function as an argument containing the route parameters. params.id refers to the unique identifier of a film and the purpose of the load function is to extract the id from the route parameters and return it. The id is then used to load or fetch the specific film data from your Django or whatever backend/data source you use. By doing this, the application can dynamically display the details of the film that corresponds to the unique id in the URL. This is pretty much the butter to the bread which we call +page.svelte.

TypeScript Tortur......I Mean Fun 🙃

*MR. PBH voice* Oooooooweeeee, this one was a doozie! I haven't touched or even looked at the docs of Typescript before adding it to this project but sometime late last year, there was a podcast I was listening to talking about how it'll change the way you code and look at JS forever once you dive in and work with it in a couple of projects. I was never a rockstar at JS in the first place so at first, I was telling myself I needed to get better at JS before getting into TS but then I thought.....why wait 😂. Let me tell you the struggle was real but well worth it. There are a handful of things I would have missed or didn't realize would have caused issues during runtime. The things that I got the most errors for were related to naming my variables and how data was passed in functions. There was a need to explicitly provide a data type or give it a type of any, but you'd do good to try and avoid using any since that's a cop-out that can bite you in the ass down the road with a bigger project as it grows. For example, I needed to define variables related to the data keys in my model so that my movie cards populate and update properly. In JS you'd just create a let or const like so:

  let name;
  let director;
  let release_year;
  let description;
  let imageFile;
  let film;
  let id;

Seems pretty simple right? But a lot of things can go wrong with this data. In my case, with the Django model only accepting certain data types for each input field when receiving and retrieving the data, it's important to make sure that my logic is solid when it submits that data during runtime. The Typescript way of defining these variables is:

  let name: string = "";
  let director: string = "";
  let release_year: string = "";
  let description: string = "";
  let imageFile: File | null = null;
  let film: Film | null = null;
  let id: number;

Here you can see the need to explicitly classify these variables as they are. There are a few caveats with each value, like strings needing to be set to an empty or default value. But when it comes to handling images, "Typescript got hands" is how I would describe how it kicked my ass trying to figure out how the hell I needed to work with the imageFile variable. But through some digging and questions, I was led to the docs for the File Interface. I'm not going to go into specifics on that particular interface but I will elaborate on what I learned about Typescript interfaces in general.

Interfaces

TypeScript's main thing is that it checks types based on the shape of values. This approach is often referred to as “duck typing” or “structural subtyping”. In TypeScript, interfaces are key. They're used to name these types and are an effective tool for defining agreements within your code and also with code that's outside of your project.
I only needed to create one interface for Films and you can see how the film-store.ts file was structured with my Film interface here:

import { writable } from "svelte/store";

export interface Film {
  id: number;
  name: string;
  director: string;
  description: string;
  release_year: number | null;
  image: string;
}

export const FilmStore = writable<Film[]>([]);

This code sets up a Svelte store to manage a list of films in my application. As you might see in my repo, I am now able to access/subscribe to FilmStore in other parts of the application, super useful and power-charged with TS. Other parts of the frontend aren't new concepts to me so we won't dive into every little thing I did before I started working on my backend branch.

Build-A-Backend

This is the first project in which I used Django. I decided to stick with learning and working with Django over Flask because I found their documentation to be much more organized and maintained. Django is also a better fit when it comes to working with Postgres or any SQL database. I can still do it with Flask, but there would have been much more setup needed and additional libraries, like Gunicorn for the WSGI Server, Alembic for database migrations, and SQLAlchemy for ORM just to name a few. There is a bunch more to add for a full-fledged app and not having to worry about that each time is a time saver. One downside though, is that some projects (including this one) don't use all that Django offers. That's just a small inconvenience though as I would have had a way larger inconvenience working with Flask down the line with my main project since it's not easy to use CockroachDB with Flask. The main reason is because of Django's built-in ORM, which can handle the nuances of the database like connection management, transactions, and data integrity. Cockroach Labs only has documentation for Django as well so that swayed me as well.
I'll do a project with Flask at some point this year but right now, I'm leaning on the tools with better learning resources. With that being said, let's get into the backend of my project

Django ⛓️ Unchained

Working with Django started pretty slow. There's a lot to understand about how things work with the framework but after the basic setup was complete, building out the needed models and views was easy enough to code up. I'll admit that I will still need to go over docs the next few times when starting up my backend since I'm still trying to wrap my head around some of the concepts. The core concepts I'd note for Django that stuck with me would be MTV (Model-Template-View) Architecture, ORM (Object-Relational Mapper), Admin Interface, and Migrations.

MTV (Model-Template-View) Architecture

Model: Represents the data structure and manages the business logic of the application. It is responsible for retrieving and storing data, as well as performing any necessary data processing.

Template: Defines how the data is presented to the user. It is responsible for rendering the HTML and displaying the data from the Model.

View: Acts as a bridge between the Model and Template. It receives user input from the Template, processes it, and updates the Model accordingly. The View also retrieves data from the Model and passes it to the Template for rendering.

ORM (Object-Relational Mapper)

I've spoken about the ORM before but just to hammer it in, Django’s ORM allows me to interact with the database using Python code instead of SQL. That's about the simplest definition I can provide.

Admin Interface

The admin interface was my favorite aspect of working with Django and i read into libraries that can accomplish this with Flask as well. But having an admin panel in general is a great tool for working with the DB and being able to create a SuperUser and account with just a few commands makes the admin setup as smooth as Prince-permed hair.

Migrations

I didn't work with migration other than migrating my initial model setup. Any changes to your models and views would require you to make another migration but again, very straightforward scripts that have already been set up in the framework made the updates easy.

I'd say I spent more time on the front end than I did on the backend setup so there isn't much to talk about other than creating the models.

Film Model

Creating the Film model required fields like Name, Release Year, Description, Director, and Image. I used SQLite over CockroachDb for this one for its simplicity and compatibility with Django's default settings. The Film model in Django is intuitive and ensures clean data inputs:

from django.db import models
from django.core.validators import MinValueValidator, MaxValueValidator
from datetime import datetime


class Film(models.Model):
    name = models.CharField(max_length=128)
    release_year = models.IntegerField(validators=[
        MinValueValidator(1900),
        MaxValueValidator(datetime.now().year)
    ],
        default=datetime.now().year
    )
    description = models.TextField(max_length=356)
    director = models.CharField(max_length=128)
    image = models.ImageField(upload_to='images/')

    def __str__(self):
        return self.name

As you can see here, I have my imports so I can utilize Django's model class. A new Film class is created and it inherits from models.Model, making it a Django model, so it's tied to a database table. Within this Film class, you see all of my model keys mentioned earlier with constraints tied to them for cleaner data inputs. I want to highlight my image key and note that for the images to be stored, I created a media and image folder (/media/images/), and directed the image uploads to be managed there. One thing I didn't get added was the removal of those images from the folder when a film is deleted. What happens now is, that the data is removed from the DB and the state + store is reset/removed from the front end, but the actual image file lingers in the repo so this can cause a major issue with a bigger app that takes in a bunch of create and delete requests a day. But I'll be my only enemy here so that's a feature I was going to try and add to this project for improvement.

Complete But Room For Improvement

With all that said, the project is complete and works. You can run both the front end and back end of the site to start. The homepage is just a title and this is 1 section that I plan to improve by just adding some basic designs and content about the project. To run the project, you would need to open up 2 terminal tabs, 1 for the front end and 1 for the back end. You can check out the README on the git repo for a detailed doc on how to get started but below is a video of me booting up both the front-end and back-end + navigating through the app a bit:

Conclusion

That wraps up my project! Folks should expect more features to come to this project like Tagging/Sorting, Authentication, and Deployment, but I knocked out the deliverable for my 1st Svelte + Django project and everyone is welcome to test it out and and tell me everything I did wrong or can do better 😄.
My next goal is to choose one of 2 tasks:

A) Work on a project that involves CockroachDB. Most likely a workshop they have on their "University" site https://university.cockroachlabs.com/.

B) Build a stock analysis app with Svletekit to get more practice with consuming third-party APIs and working with Svelte store and local storage.

I'm leaning towards B since I do need more work with APIs but I also want to get through a small project using Cockroach to get my feet wet there. I'll make my decision and provide an update in my next post, which will be "Day 26 of 100-Days-of-Python-Code". I think I'm pretty on pace with the phases I made for myself. My Goal for the full-fledged Personal Finance Tracker app was to have it complete within a year, which is double the total time of the phases (6 months) since I'm not doing this full time and like to enjoy the other things in life as well. But here is the Repo for the project -> https://github.com/kdleonard93/film-fan so check it out! After the next project for practice, I'll begin my work on the main app 🤘🏾.

If you want to keep up with my writing or want to connect as peers, check out my social links below and give me a follow!

• 𝕏 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Today I completed Day-25 of my 100 Days of Python journey. The challenge? To deepen my understanding of Pandas through a project that, honestly, wasn't the most thrilling – a U.S. States guessing game. Sure, it sounds mundane, but it's crucial stuff, especially since handling CSV files with Pandas is a fundamental skill in the world of finance apps. So, let's dive in and break down this project, tedious as it might have been!

🎨 The Toolbox: turtle & pandas

For this project, we only needed two libraries: turtle and pandas. Turtle is like the old reliable of Python teaching tools. It's great for learning Python basics through small, graphical projects.

And then there's pandas – the data wizard of Python. Think of it as your go-to tool for manipulating structured data like CSV files. In this project, pandas was the key to managing the game's data, from importing state info to exporting our "to-learn" list. 📊📝

🕹️ Setting the Scene: The Game Screen

The first order of business was setting up our game screen, creating a new window titled "U.S. States Game" and decking it out with a background image of a blank U.S. map. The image is a .gif file since the turtle library only works with those files for use within its methods. For example:

pythonCopy code    image = "blank_states_img.gif"  
    screen.addshape(image)
    turtle.shape(image)

With these lines, we're utilizing turtle's addshape() and shape() functions to integrate our map into the game.

📚 Crunching Data with Pandas

Next, we harnessed the power of pandas to read a CSV file named "50_states.csv". This file was essentially the game's backbone, storing the names and coordinates of all U.S. states. We transformed this data into a list called all_states, setting us up for the game's logic. 🗺️

🎮 The Gameplay: Guessing the States

This is where things got a tad more interesting. We started with an empty list, guessed_states, to track correct guesses. The game looped, prompting for state name guesses. Typing "Exit" would end the game and save a list of states still to be guessed into "states_to_learn.csv". A nice little feature to keep the challenge going! 🏁

✍️ Marking the Map: Displaying Guessed States

Every correct guess brought a new turtle onto the scene to mark the state's name on the map. Simple, yet effective. You can find the project here if you wanna check out the code -> Github Repo.

So, that wraps up Day-25. While the project didn't exactly set my world on fire, it did reinforce some key skills. But let's be real, my mind kept drifting to a more exciting project...

Teasing FanFlix

The working title? FanFlix. It's not set in stone, but the project itself is something I'm pretty pumped about. It's a CRUD app blending Svelte's sleekness with Django's robustness. I'm still chipping away at it, and I'll share more in a dedicated post once it's up and running. Stay tuned for a real-world example of Svelte and Django in harmony – something that's not too common out there.

📢 Let's Connect!

Got any thoughts on Python, game coding, my main project, or just tech in general? Hit me up and lets chat!

• 𝕏 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Hey folks, after a bunch of quick trials with a bunch of different stacks, I finally settled on what I'm going to focus on with this project. The projection of a project of this size is about 6 months but knowing how I work and what I have going on in my personal life, I'm hoping to have a working app within a year. The new tech coming out these days has sent me down many rabbit holes, resulting in me wanting to use all of it in my day-to-day activity 😄. With that urge aside, I needed to make a decision on what I was going to use for the Personal Finance app mentioned in my last post. I have a hard time making decisions as is on tech stacks and the idea of needing to learn new technologies when I'm still perfecting languages I use in my salaried job is exhausting and pretty daunting at times. But I know the pain and constraints with tried and true technologies and at my point in my career, I feel these new technologies are going to become more relevant and needed in this evergrowing industry where exponential growth is imminent. My main goal is still a career working with Python but to also try and pinpoint the finance industry, whether it's big tech or freelancing, hence this project. The tech I've worked with for deciding my stack (New to Old) includes SvelteKit, Python (Django + Flask), Bun (for frontend package management), Docker, CockroachDB, FaunaDB, Cloudflare, and Redner. While all of these tools had their use cases, I ended with SvelteKit + Typescript for my front-end, Python w/ Django for my back-end, and CockroachDB for my database. I plan to deploy on Render (That's still to be determined though.) Was fun and frustrating during this trial but my reasoning behind my choice is pretty sound in my opinion.

Sticky Stacking

When I first started this project, I went in with the idea of 100% using a serverless database, whether it was Relational or Non-Relational. So out of the available options, I tried out CockroachDB and Fauna DB.

Svelte Sorcerer

Out of all of the frontend frameworks out there these days, Svelte won me over for its easy learning curve and simplicity. I compared mainly Vue and Svelte, but Solid.js and Qwik were also considered. I didn't even consider Recact cause I have personal issues with that framework and is just a "me" problem 😂. The winner though, was Svelete for many reasons:

1. Performance: Svelte's compiler approach ensures that the final bundle size is smaller and the runtime performance is faster. For an expense-tracking app, which likely involves numerous interactive elements and frequent updates, Svelte’s efficient update mechanism can make the UX much smoother for the customers, aka myself and my lady.

2. Ease of Development: Svelte's syntax is simple and intuitive, and has less boilerplate code (especially related to react). This should make the development process faster and more straightforward, especially since this project shouldn't call for highly complex functionalities.

3. State Management: Ahh yes, state management. Svelte’s reactive state management is straightforward and built-in, eliminating the need for additional state management libraries. This is a godsend for me since managing state was always difficult (*cough* react *cough*). This simplifies handling user inputs, server responses, and UI updates, which are core aspects of an expense-tracking application.

4. Learning Curve and Productivity: I've been reading into Svelete for some time now but just recently using it in a project (*new portfolio below*), and its learning curve isn't as steep as other frameworks. I was scaffolded and going pretty quickly with a skeleton project. The clear and concise codebase can also be easier to maintain and scale.

5. SvelteKit for Full-Stack Development: If the expense tracking app requires both frontend and backend development, SvelteKit offers an all-in-one solution, streamlining the development process. It provides features like server-side rendering, static site generation, and file-based routing, which can be very beneficial.

Django Dogg 🐕

Regarding the backend framework, Django won the battle here against Flask. I experimented a bit with both and my decision was pretty back and forth, but all in all, Django fits this project's needs the most. Some of the key features for choosing Django:

1. Structured and Feature-Rich: Django's "batteries-included" approach provides a lot of built-in functionalities that I learned are beneficial for this app. The admin interface (best feature in my opinion), user authentication, and ORM are particularly useful. The admin interface can be quickly customized to manage expenses, categories, and user accounts, which would be a significant part of an expense-tracking app.

2. ORM and Database Management: Django's ORM is powerful and simplifies interactions with the database. For an expense tracking app, where you'll be dealing with a lot of CRUD operations, Django's ORM can make these tasks more manageable and efficient.

3. Security: Django totes its robust security and helps avoid common mistakes like SQL injection, cross-site scripting, cross-site request forgery, etc. For an app dealing with personal financial data, security is essential.

4. Scalability: While Flask is also scalable, Django's structure and components make it easier to scale for larger applications. If the expense tracking app grows in complexity or user base, Django can handle this growth more readily.

5. Community and Ecosystem: Django has a large community and extensive documentation, which makes finding solutions to problems easier. There are also a bunch of dope packages to extend Django, adding functionality and/or simplifying development.

Durable like a Cockroach 🪳

Choosing between these two was my biggest decision and ultimately came down to which would be easier to set up and what worked better with my backend choice. After playing with Fauna first, I chose CockroachDB because I was planning on using Django as my backend framework and I was familiar with SQL. On the other hand, I am very familiar with JSON and work with it a good amount at my company, so Fauna's JSON-like document model was pretty attractive. The issue I found with Fauna though, is that there's not a lot of support out there in terms of resources and community, making using this for a large project a difficult task. When trying out CockroachDB, the learning curve, to me, seems to be a bit steeper but they have much more learning material. They also have more organized and richer documentation with a load of resources in what they call "Cockroach University". These resources include quick projects, webinars, and free courses that offer certificates upon completion. This makes CockroachDB an easy winner for this particular project, but I still plan to build something with Fauna at some point this year. Here are the main reasons for CockraochDB summed up

1. Strong Consistency: For a financial application, data consistency is crucial. CockroachDB's strong consistency model ensures that all transactions are accurate and reliable, which is paramount in handling financial data where errors or inconsistencies can have serious consequences.

2. Distributed SQL Database: CockroachDB's architecture is inherently distributed, making it highly resilient and suitable for applications that require high availability and fault tolerance. It's said to be especially beneficial if the app needs to scale or maintain high uptime. FaunaDB offers a distributed serverless platform as well so this was kind of a tie.

3. Transactional Data Integrity: CockroachDB supports full ACID transactions, which is important for an application dealing with financial records. Ensuring the integrity of each transaction (like adding or modifying expense entries) is essential, and CockroachDB's focus on transactional integrity aligns well with this requirement.

4. SQL Interface: The use of standard SQL in CockroachDB can be a significant advantage. SQL is an OG in the database game, making it easier to find developers familiar with it or to work within a team that already has SQL knowledge. This could lead to a smoother development process and easier maintenance. I know we use MySQL at my company so having access to public AND company resources are nice to have for learning and troubleshooting.

5. Scalability and Geo-Distribution: CockroachDB's scalability and support for geo-distributed clusters can be advantageous if the app grows in user base or if there's a need to provide low-latency access to users in different geographical locations.

Diving in off the Dock(er), no Bun intended...😏 🥁

I started out wanting to containerize this application while using Bun to serve up my app. I was put in my place immediately 😅. The complexity of getting Bun set up with Docker is not well documented whatsoever and the few example projects I saw were a bit too basic for me to apply what they were showing to this project. So my idea is to just stick with using node and (possibly) implement bun after launching the project as an enhancement. I understand Docker enough to get around some troubleshooting for my work at Cars Commerce, but I'm no expert whatsoever. So I'm banking on this project to bring along some good lessons (and plenty of challenges).

Project Concept

Objective: My journey with the "Personal Finance Tracker" is not just about developing a project; it's about crafting a personal financial assistant. This tool, grounded in advanced analytics, aims to provide precise financial health forecasts. My goal is to empower not only myself but potentially others as well, enabling more informed decisions about finances.

Project Significance: More than a mere technical endeavor, this project is a deeply personal endeavor aimed at demystifying financial management for a broader audience, ranging from lower-income communities to students, and working professionals. Through predictive analytics, my ambition is to boost financial literacy, guiding users to navigate through financial challenges and plan proactively for their future.

Understanding the Scope

Key Features – From Concepts to Reality

1. Tracking Income and Expenses: A core feature where users can log and monitor their finances for a crystal-clear view of their financial status.

2. Categorizing Financial Transactions: An automatic system to categorize transactions – making it simpler to understand spending habits and pinpoint areas for improvement.

3. Predictive Analysis (extra credit): Using historical data to forecast future expenses and savings, aiding in strategic budget planning and financial decision-making.

Intended Users: From budget-conscious individuals and students to long-term investment planning professionals – this tool is designed for anyone looking to upgrade their financial management skills.

Use Cases: Whether it's regular budget tracking, setting financial goals, forecasting expenses, or identifying savings opportunities, this tool aims to cover it all.

Technical Journey and Choices

Technology Stack Decisions

1. Frontend: After exploring various options, I've landed on SvelteKit with TypeScript and Vite. Their modern architecture and fast rendering capabilities promise a seamless user experience.

2. Backend: I chose Python with Django over Flask for its flexibility and simplicity – crucial for future customizations.

3. Database: CockroachDB won over Fauna for its strong consistency, transactional data integrity, and rich documentation for newcomers.

Extra Tools: I plan to Dockerize my app. Bun was considered, but it's currently on the "extra credit" list, possibly integrated at the project's end as an enhancement.

Rationale Behind Choices: Each piece of the tech stack was selected for its strength and industry relevance. SvelteKit for frontend efficiency, Python and Flask for a flexible backend, and FaunaDB for robust serverless data management – a combination that I believe will address the needs of this project effectively.

Project Timeline and Milestones

Rough Timeline

• Phase 1: Conceptualization and Planning (Month 1)

• Phase 2: Development of Core Features (Months 2-4)

• Phase 3: Integration and Testing (Month 5)

• Phase 4: Launch and Feedback Incorporation (Month 6)

• Note: Aiming for completion within a year, considering personal and professional commitments. Timeline adjustments are possible.

Key Milestones

• M1: Project Blueprint and Requirement Analysis (End of Month 1)

• M2: Alpha Version with Basic Features (End of Month 3)

• M3: Beta Version +Predictive Analysis (End of Month 5)

• M4: App Launch (End of Month 6)

New Dev Portfolio & Anticipating the Journey Ahead

I'm pumped again as I venture deeper into this project, eager to immerse myself in the technologies I've chosen and tackle their challenges. Over the last couple of weeks, I took a long and much-needed vacation. During that time I built a new dev portfolio and added it to a domain I picked up last year with a vision of what I'm trying to offer and contribute to the space of development: Digital Dopamine.

This blog post marks the beginning of a new series dedicated to this project, where I'll be sharing detailed plans and technical insights as the project unfolds. Alongside, I'll continue my journey with the 100-days-of-python challenge. While it might seem monotonous at times, I told myself I was going to complete it and I'm committed to seeing it through (no matter how much interest I lost in it 😅).

For those interested in following the project's progress, feel free to ⭐️ and 👀 the repository here: Leo_Ledger on GitHub. Let's get to work!

If you want to keep up with my writing or want to connect as peers, check out my social links below and give me a follow!

• 𝕏 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

After the Email Sender project, I scouted again to see what would be an excellent project but a bit more challenging and more practical for day-to-day use (I don't plan to actually use the auto email sender....at least not yet 😁). So after discussing things I could do that would benefit both of us, we figured that a Twitter bot would help us both. She'd have a tool to automate her Twitter posts of her plants and I'd get some practice building out Python bots. It seemed easy enough to get all of the details:
- Set up a Twitter Developer Account
- Code the Bot
- Spice up the bot
- Deploy the Bot

Tweepy is the popular library of choice for working with Twitter's API and their documentation is understandable. For the sake of clarity, I'm going to reference X as Twitter (like the good lord intended 😂)

API Permissions are the battle

The main issue I'm having with this bot creation is with API Permissions. Tweepy's docs help a good amount but I'm not sure what I'm missing between their doc (https://docs.tweepy.org/en/stable/authentication.html#twitter-api-v2) and Twitter's (https://developer.twitter.com/en/docs/twitter-api/tweets/manage-tweets/api-reference/post-tweets). My permissions for the Twitter account are for API V2 and restricted V1 access. However, no matter what I did to change the code to get a post to work, I kept getting an error about API permissions.

I tried to see if I could access the few API v1 endpoints I had access to but that didn't work either. My working repo is here -> https://github.com/kdleonard93/Twitter_bot and you can see how I currently have it set up (if anyone knows what I'm doing wrong let me know 🙏🏾). Most attempts were to the POST endpoint but I tried to GET a list of recent tweets as well as read my follower count but no luck there either. The closest I got was where I had a setup that prompted me to navigate to the URL provided to get a code to authenticate, but once I go to that URL (Which has my ID, redirect URL, and Username data in it) I get an error. https://loom.com/i/96fe0e1cb1b740ccbe5c4f9437c60cc5

After coming back to this a handful of times with a "fresh mind" but no progress with this issue, I've decided to pause it and see if any of my peers might know what I'm missing, instead of frustrating myself day in and day out. Considering that my lady still needs to create the content that I'd be posting (listing images, deals, etc.) I can take a breather and work on something else while I try to source some guidance. That led me to move on to Day 24 in my 100-Days-Of-Python course (yes....I'm still planning on finishing all 100 days 😄) as well as pick a new project that is more useful for now while I figure out the Twitter bot and wait for content to post. The new project is a "Personal Finance Tracker with Predictive Analysis". The predictive analysis portion of the project is extra credit since it will involve ML which I have never dove into. This might also sound more difficult than the last project, and I'm sure it is 😅, but it's something fresh that I need.

Day 24 - Files, Directories, and Paths

This day came pretty easy. It's pretty much just an overview of directories and how to access the files within through relative and absolute paths. Reading and Writing files are easy peasy as well utilizing one main method, open(). open() returns a file object, and is most commonly used with two positional arguments and one keyword argument: open(filename, mode, encoding=None). The first argument is a string that will be the file name or the path to the file you're trying to read. The mode argument is to determine which way the file is to be used. You can read mode="r", write mode="w", and append mode="a" for most people's needs. There are a couple more, like r+ for reading and writing and b for opening the file in binary mode.

A quick example of this would be:

open('letter.txt', 'r')
or
open('letter.txt', mode='r')

Personally, I prefer open('letter.txt', mode='r') so whoever reads the code, is provided more clarity on what that is doing, but to each their own. This leads us to a nice lil' trick for Python to ensure the file closes after the update is made. We do this by using with and as like so:

# Example 1
with open('letter.txt', mode='w') as new_letter:
    """The text below will update whatever text is on letter.txt"""
    new_letter.write("New letter, who dis?")

# Example 2
with open('letter.txt', mode='r') as new_letter:
    """The call below will read letter.txt and store the data in `contents`."""
    contents = read_letter.read()
    print(contents)

# Example 3
with open('letter.txt', mode='a') as new_letter:
    """The call below will append the added text to letter.txt at the end of the file."""
    new_letter.write("It's ya boi, that's who?")

There's more to learn about "Input and Output" though and I recommend taking a peek at the docs -> https://docs.python.org/3/tutorial/inputoutput.html#reading-and-writing-files.

The Project - Mail Merger Project

The project for day 24 was not as hefty as some of the more recent days, which I appreciate very much ( ͡⏿ ͜ʖ ͡⏿). The goal was to take a list of names from a given doc and create email drafts for each person. The content was the same but the names needed to be swapped out for each new file and labeled as such in the file name and body copy. Outside of using a for loop, this project consisted of only what we learned on day 24 and the code is brief:

PLACEHOLDER = "[name]"

with open("/Users/kyleleonard/100-Days-Of-Code_Python/day-24/Input/Names/invited_names.txt") as names_file:
   names = names_file.readlines()
   print(names)

with open("/Users/kyleleonard/100-Days-Of-Code_Python/day-24/Input/Letters/starting_letter.txt") as letter_file:
    letter_content = letter_file.read()
    for name in names:
        stripped_name = name.strip()
        new_letter = letter_content.replace(PLACEHOLDER, stripped_name)
        with open(f"/Users/kyleleonard/100-Days-Of-Code_Python/day-24/Output/ReadyToSend/letter_for_{stripped_name}", mode="w") as completed_letter:
            completed_letter.write(new_letter)

That's it! Now the files created from running this are listed in the repo and you can check it all out here -> https://github.com/kdleonard93/100-Days-Of-Code_Python/tree/main/day-24.

EOD

My main goal now is to get started on that other project I mentioned while also tackling days 25-30. I'm starting to wind down with all the weddings vacations, birthdays, and everything in between, and am VERY happy about it. I never realized how exhausting travel could be when you're doing it in succession for a few months. Nonetheless, there are a couple of new things out in the dev world that have been released over the last month:

• Bun - A JS runtime & toolkit (Stable version)

• Mojo - A superset of Python built for AI (No stable version yet but an SDK is available)

These 2 intrigue me the most and I plan to use Bun as my runtime for my new project. I know this will inevitably cause me a headache with the impending wall of errors I plan to face. It should be good for me though, forcing me to get acquainted with Bun and maybe even trying to contribute to it or other open-source tools I use. Fingers crossed 🤞🏾 and until next time, ✌🏾.

If you want to keep up with my writing or just want to connect as peers, check out my social links below and give me a follow!

• 𝕏 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

What's up, folks! I wrapped up this project last night and early this AM and it's safe to say it was a pretty decent challenge along the way. When picking a "beginner" Python project to work on, I didn't expect it to last as long as this Email Sender did, and I definitely didn't expect the amount of work that actually had to go into getting this project to work successfully. Throughout the course, I did my best to follow the best practices when it comes to commits and PRs (Like I've been doing my 100 Days of Python Code challenge *still ongoing 😅*) but will admit some commits were pushed directly through the master. I also created a proper README for anyone who wants to pull the project for themselves and use it! It's fully functional and you can modify it accordingly as you please 😁. The full project repo can be found here -> https://github.com/kdleonard93/automated_email_sender.

Reflection

What a ride this project has been! 🚀 Remember Day 1? Me neither because it was a blur of setting up Python environments and sorting out initial roadblocks like version control (yeah, Git, I'm looking at you 😅). But once the basics were nailed, the ball started rolling.

One of the big wins was getting scheduling right on Day 6. Man, figuring out how to automatically send emails based on a CSV file was very helpful and a challenge in itself. But now, If you've got a list of people to email and specific times to do it, just fire and forget! Gotta love automation.

I also took the security aspect seriously, keeping passwords and other sensitive stuff out of the GitHub repo by using .env and .gitignore. Can't trust the internet, ya know 😂?

# .env example
EMAIL_PASSWORD=YourEmailPassword
SENDER_EMAIL=YourSenderEmail
SMTP_SERVER=YourSMTPServer
SMTP_PORT=YourSMTPPort

# .gitignore example
.env
email_data.csv
email_log.csv 
venv/

Now, you might be wondering about stress testing. To be honest, I haven't dived into it yet, but it's on my radar for sure. I plan to tweak and refine this project over time, and that’s when I'll throw the stress tests into the mix.

All in all, it's been a whirlwind of code, tea, and a smidge of destressing 😄. Can't wait to see where this project takes me next, and what new skills I'll add to the ol' toolkit next. 🛠️

If you want to keep up with my writing or just want to connect as peers, check out my social links below and give me a follow!

• 𝗫 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

I know, I know, I said "This Project should only take me a couple of weeks".....well, here I am 4 weeks later and only halfway through lol. Went to Canada for a bachelor party and have been finishing up house projects, so lots of moving parts recently. Add the aspect of needing to learn more libraries ad you have a major delay in getting this completed 😅.

The meat of the project is done though! You can go over to my repo here -> https://github.com/kdleonard93/automated_email_sender and check in on the commits made since I started this project. Feel free to pull it down and give it a try yourself. Please note though, if you wanna try it out, you'll need to make a few adjustments:

1. Update the sender_email argument value in the send_email function to your own (you'll need to use Gmail). Change the recipient's email as well. (Dont you dare use mine lol)

2. Make sure you set your password in an environment variable since we are storing sensitive data (aka: password). You can do this in your terminal by running export EMAIL_PASSWORD=your_password_here .

3. Lastly, confirm all of the needed libraries are installed on your local.

Once you have the following checks and this repo pulled, run python main.py and you should be set!
As I was writing this, I realized the amount of other sensitive info I had in the project (emails, env variables, etc.) So I made some code changes already to improve the project 😄.

For those who wanna see a quick snippet of the email_sender.py file, you can take a peek below:

import smtplib
import ssl
import csv
from email.mime.text import MIMEText
from email.mime.multipart import MIMEMultipart
import schedule
import time
from os import environ
from dotenv import load_dotenv

load_dotenv()  # This will load environment variables from a .env file.

PASSWORD = environ.get("EMAIL_PASSWORD")
SENDER_EMAIL = environ.get("SENDER_EMAIL")
SMTP_SERVER = environ.get("SMTP_SERVER")  # Set up the SMTP server and port
SMTP_PORT = int(environ.get("SMTP_PORT", 465))  # For SSL

# Check if necessary environment variables are set
if not (PASSWORD and SENDER_EMAIL and SMTP_SERVER):
    raise EnvironmentError("Required environment variables are missing!")


def read_email_data(filename="email_data.csv"):
    email_data = []
    with open(filename, "r") as file:
        reader = csv.DictReader(file)
        for row in reader:
            email_data.append(row)
    return email_data


def send_email(email_data, sender_email=SENDER_EMAIL):
    # Create email headers and body
    message = MIMEMultipart()
    message["From"] = sender_email
    message["To"] = email_data["recipient_email"]
    message["Subject"] = email_data["subject"]
    message.attach(MIMEText(email_data["body"], "plain"))

    # Create a secure SSL context
    context = ssl.create_default_context()

    # Try to log in to the server and send the email
    try:
        server = smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT, context=context)
        server.login(sender_email, PASSWORD)
        server.sendmail(
            sender_email, email_data["recipient_email"], message.as_string())
    except Exception as e:
        print(f"An error occurred while sending the email: {e}")
    finally:
        server.quit()


def send_multi_emails(filename="email_data.csv"):
    email_data_list = read_email_data(filename)
    for data in email_data_list:
        send_email(email_data=data)


def job():
    """Define the job to be executed at a scheduled time."""
    send_multi_emails()


def email_schedule(interval):
    """Schedules the email sending job."""
    schedule.every(interval).minutes.do(job)
    while True:
        schedule.run_pending()
        time.sleep(1)

One thing I will admit to is that the automation for this had me stuck for a little. Learning a lot about security practices with this one as well and will need it for future projects so I've been appreciating the challenge.

EOD

Wish I was able to get a check-in written sooner but, you know.....life. The last few things I need to do is create a log for the jobs, do some final testing after that, and then reflect and write my final thoughts on this project! See yall then!

If you want to keep up with my progress or just want to connect as peers, check out my social links below and give me a follow!

• 🐦 Twitter (Not calling it X yet...doesn't roll off the tongue lol)

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Hey folks, been a little over a couple of weeks since I posted but I had a big move out of the city that I finished up last week and we just got done unpacking and setting up most of our home. Lots of went into refurbishing, and my girlfriend and I enjoyed tackling these DIY projects sprinkled around the house. My workspace is shaping up well, and I didn't anticipate how personalizing my office could enhance focus while working remotely, reducing feelings of isolation or the desire to escape to coffee shops for a change of scenery (previously I had old roommates and lacked a dedicated home office, making do with my bedroom and living room.)

With being said, I had the urge to switch up my next couple of weeks to continue practicing what I've learned so far in Python, as mentioned in my last post. Also, I was getting kinda sick of working with the turtle module for EVRY SINGLE PROJECT 😅. While it's excellent for kickstarting the learning process, particularly with creating some classic games, it soon became monotonously familiar. So rather than merely tackling a handful of CodeWars challenges a few days a week and bouncing to the next course day, I intend to intersperse some standalone projects to further solidify these concepts. I genuinely need to master the nuances of OOP to enhance my skill in refining and updating existing code, all to progress in my present job and take on tougher tickets. I'm banking on these projects to secure that knowledge. For me, repetition is key; I've been working on boosting my cognitive health for some time to help improve retention.

The Project

The project that I'm going to work on over the next couple of weeks is an Automated Email Sender. I researched beginner-friendly projects that involve automation, in an attempt to gradually advance towards more complex projects like chatbots and trading bots, and then eventually, NLP. I actually made one crypto trading bot not too long ago but so far, it carries out my orders with a "taker's fee" and does so at the prevailing market price instead of the limit price I've set with the "maker fee" only (maker fees are generally less than taker fees).
I'll refrain from veering into a discourse about trading bots and the like, so back to the topic at hand 😄. After researching this project I noted some of the common libraries used as well as a game plan on how to tackle each day. Here's an outline of the project and resources required to hit the ground running:

MVP (Minimum Viable Product):

1. Send an Email: The program should be able to send an email to any address.

2. Customize the Subject and Body: The user should be able to input the subject and body of the email.

3. Send Multiple Emails: The program should be able to send multiple emails, either to the same address or to different addresses.

4. Schedule Emails: The user should be able to schedule emails to be sent at specific times.

5. Log Sent Emails: The program should keep a log of all sent emails, including the date and time, recipient, subject, and body.

Libraries Needed:

• smtplib: This is the built-in Python library for sending emails using the Simple Mail Transfer Protocol (SMTP).

• ssl: Another built-in Python library. I'll use it to create a secure connection with my mail server.

• getpass: This built-in library is used for secure password handling.

• schedule: This is an external library that I can use to schedule emails to be sent at specific times.

• pandas: I will use this library to create and manage a DataFrame that will serve as an email log.

Optional Libraries:

• os: If you want to make your log persistent across runs (i.e., save it to a file), you'll need this library to interact with your operating system's file system.

• datetime: For working with dates and times, useful for scheduling and logging.

Estimated Timeline:

• Days 1-2: Research the needed libraries and setup the project. Draft the program by defining the main functions and how they'll interact.

• Days 3-4: Write the function to send a single email. Test this function to make sure it works correctly.

• Day 5: Write the function to send multiple emails. More tests.

• Day 6: Add scheduling capabilities to your program. You guessed it, +Testing.

• Day 7: Create the email log. "Testing testing, 1-2-3".

• Day 8: Do a final round of testing and debugging on the project as a whole to make sure all parts of the program work together correctly.

• Day 9: Polish project; Clean up code, add comments, write documentation, and anything else needed to wrap up the project.

• Day 10: Reflect on the project, and plan your next steps.

The project timeline is predicated on full-time work, so since this is a part-time endeavor, it'll take me roughly 2 weeks, as previously mentioned. I've initiated the repo and you can follow it on GitHub here -> -> https://github.com/kdleonard93/automated_email_sender

EOD

How I intend to document all of this is still under consideration. I might opt to write a midway and final report OR perhaps just a wrap-up post at the end. Likely the former, and maybe even a third if I stumble upon an exciting add-on to this project. But that brings today's post to a close, and I'm excited to get this one going!

If you want to keep up with my progress or just want to connect as peers, check out my social links below and give me a follow!

• 🐦 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Breaking down the Problem

So we need to figure out how to exactly get the game set up and below is how we broke down the project:

• Move the turtle up with a specified keypress

• Create and move cars

• Detect collisions with cars and display a "GAME OVER"

• Detect completion of the game and start a new level

• Create a scoreboard.

The Project

Since this is a capstone project, I'm going to go into more detail about what exactly we did in each file, but I'll still only post a snippet or two, leaving the whole repo to be viewed on GitHub -> https://github.com/kdleonard93/100-Days-Of-Code_Python/tree/day-23/day-23.

With the final lines of code in place, our Turtle Crossing Game has taken shape, showcasing the capabilities of Python's Turtle module and the OOP principles I've been practicing. Let's take a closer look at what we've accomplished.

We start off with our main.py file, which serves as the core of our game. Here, we set up our game screen, initialize our player, car manager, and scoreboard, and keep the game running as long as our turtle dodges traffic. Below is a snippet of the code from main.py:

import time
from turtle import Screen
from player import Player
from car_manager import CarManager
from scoreboard import Scoreboard

screen = Screen()
screen.setup(width=600, height=600)
screen.tracer(0)

player = Player()
car_manager = CarManager()
scoreboard = Scoreboard()

screen.listen()
screen.onkey(player.go_up, "Up")

game_is_on = True
while game_is_on:
    time.sleep(0.1)
    screen.update()

    car_manager.create_car()
    car_manager.move_cars()

    for car in car_manager.all_cars:
        if car.distance(player) < 20:
            game_is_on = False
            scoreboard.game_over()

    if player.is_at_finish_line():
        player.go_to_start()
        car_manager.level_up()
        scoreboard.increase_level()

screen.exitonclick()

As you can see from the code above, I import the necessary modules and initialize the game screen, player, car manager, and scoreboard. The script then starts listening for an 'Up' key press to make the turtle move. The game loop begins, controlled by the game_is_on flag, where the screen gets updated, cars are created and moved, and collision between cars and the player is checked. If a collision occurs, the game ends. If the player reaches the finish line, the player is moved back to the start, and the level of difficulty is increased. The game loop runs until a collision happens, and the game can be exited anytime by clicking on the screen.

Next, we delve into car_manager.py. We create new car objects at random intervals, color them randomly for a little excitement, and handle the movement of the cars. As the player progresses, the cars get faster, increasing the difficulty with each level. This was a bit of a challenge and you can see a snippet of this code below:

from turtle import Turtle
import random

COLORS = ["red", "orange", "yellow", "green", "blue", "purple"]
STARTING_MOVE_DISTANCE = 5
MOVE_INCREMENT = 10


class CarManager:
    def __init__(self):
        self.all_cars = []
        self.car_speed = STARTING_MOVE_DISTANCE

    def create_car(self):
        random_chance = random.randint(1,6)
        if random_chance == 1:
            new_car = Turtle("square")
            new_car.shapesize(stretch_wid=1, stretch_len=2)
            new_car.penup()
            new_car.color(random.choice(COLORS))
            random_y = random.randint(-280, 260)
            new_car.goto(300, random_y)
            self.all_cars.append(new_car)

    def move_cars(self):
        for car in self.all_cars:
            car.backward(self.car_speed)

    def level_up(self):
        self.car_speed += MOVE_INCREMENT

Then, there's the player.py file or, the turtle itself. Our turtle begins at the starting position and moves towards the finish line when the "Up" key is pressed. Upon reaching the finish line, our turtle resets to the starting position, signaling a successful level completion and displaying the current level for the player.

Which leads to the scoreboard.py file, which keeps track of the player's progress. It shows the current level and if the player is smashed by a careless driver, GAME OVER will appear in the middle of the screen.

Creating this game not only puts into practice what we've learned about Classes, Class Inheritance, and creating methods within those classes, but also tests our understanding of the Python turtle game engine.

But the beauty of coding is in its limitless possibilities, right? Angela challenged the audience to remix this game to show off some creativity and skill. I'm admittedly not going to do this extra challenge but for anyone that finds the turtle game fun should give it a shot! The turtle module is a large playground for creativity, and I've come to find there's always something new to learn and explore.

EOD

With that, I conclude Day 23 of our 100-day Python journey. Stay tuned for more fun projects and keep those coding gears grinding. Happy coding! 🤘🏾😄!

If you want to keep up with my progress or just want to connect as peers, check out my social links below and give me a follow!

• 🐦 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

Hey folks! My task for today was to conjure up the classic "Pong Arcade Game", utilizing all the knowledge and skills I've garnered thus far. Angela didn't introduce any fresh concepts and today was all concentrated on the game development. So, I'll dive into some of the riveting and tricky bits of this venture, with examples and my thoughts on why it was a pain in the ass at certain points 😄.

Dissecting the Project

Oddly enough, this might have been the least technical segment of the task, yet for some reason, my initial estimations on how to segment this project were off a bit, enough to make me double back to some of my previous notes and older lectures. The project was ultimately sectioned into the following stages:

• Create the game screen

• Create the first paddle and add movement controls

• Create another paddle

• Create the ball and make it start moving left or right

• Detect collision with the wall and bounce from that position

• Detect collision with a paddle and bounce from that position

• Detect when the paddle misses

• Keep the score

As you can see, this project is a bit more challenging than the snake game but once I finally completed it, I was happy with the end result and the skills I was able to practice!

It Either Made Sense, Or It Didn't

Parts of this project came together quite effortlessly. We've been tinkering with the turtle module for a while now and recent projects have been a breeze to kickstart. Setting up the file structure, basic imports, variables, and event handlers was a piece of cake. But, when it came to detecting the collision with the top and bottom walls as well as collision with the paddles, it was quite the mental task. I found myself either over-analyzing or underthinking and needed a bit of a helping hand. For instance, devising the logic for when the ball strikes the paddle proved to be the most challenging segment of this project for me. I had to take into account the dimensions of both the ball and the paddle while devising the logic. Another obstacle was resetting the ball's position once a score was made, while simultaneously making it move in the opposite direction to give the other player a fair start on the next round. Here's a glimpse at how the ball and bounce logic was constructed:

from turtle import Turtle


class Ball(Turtle):
    def __init__(self):
        super().__init__()
        self.shape("circle")
        self.penup()
        self.color("white")
        self.x_move = 10
        self.y_move = 10
        self.movement = 0.1

    def move(self):
        new_x = self.xcor() + self.x_move
        new_y = self.ycor() + self.y_move
        self.goto(new_x, new_y)

    def bounce(self):
        self.y_move *= -1

    def paddle_bounce(self):
        self.x_move *= -1
        self.movement *= 0.7

    def reset_position(self):
        self.goto(0, 0)
        self.movement = 0.1
        self.paddle_bounce()

Additionally, in the code snippet above, you can see that I have a movement attribute that sets the ball's initial speed, and, each time it hits a paddle, the speed is ramped up. The speed, along with the position, is reset when someone scores. There were a few more areas that required a fair amount of thought, but overall, this was an engaging project. You can check out the final product here -> https://github.com/kdleonard93/100-Days-Of-Code_Python/tree/main/day-22 and here's a short gif of me playing a round of pong solo.

Due to limitations of the free version of Zight, the gif only spans 15 seconds and I didn't want to use my work account for personal stuff so you only get to witness one point being scored lol. Here's hoping that Loom introduces gif-making capabilities soon.

EOD

Cheers to another Python game accomplished! It was indeed tough, but it was a significant step in consolidating recent knowledge and realizing that there is still more to learn. I've been spending some time on codewars.com to improve my skills and I'm contemplating devoting one or two of my weekly sessions to working on more practice problems rather than rushing into new concepts. This way, I'll be able to thoroughly grasp every aspect of this journey. Peace out! ✌🏾

If you want to keep up with my progress or just want to connect as peers, check out my social links below and give me a follow!

• 🐦 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

As I mentioned yesterday today we learned about class inheritance and how we're going to use it to build out the other classes to keep score of the game and to detect collisions with the food, the wall, and the snake's tail.

Class Inheritance

To sum it up: Class Inheritance is the ability to inherit the properties of another class in a newly created one. Imagine you have a class called Parent that has special features and methods. Now, you can make another class, let's call it the Child class, that can utilize everything from the Parent class and can add its own unique methods. So, instead of starting from scratch every time, we can reuse and extend the features of existing classes to make our code more efficient and organized.

To get this initialized you would have to call super().__init__() within the 1 __init__ function. I've added a code snippet to give a simple visual:

class Parent:
    def __init__(self, parent_attribute):
        self.parent_attribute = parent_attribute

class Child(Parent):
    def __init__(self, parent_attribute, child_attribute):
        super().__init__(parent_attribute)
        self.child_attribute = child_attribute

confession = Child("I'm the Pappy!", "That's the truth!")


print(confession.parent_attribute)
print(confession.child_attribute)

The above code will print:

This is very useful for minimizing the need to rinse and repeat for class and method creation.

The Project

So today we need to finalize the game by completing 4 objectives:

1. Detect food collision.

2. Create a scoreboard.

3. Detect collision with the wall.

4. Detect collision with the snake's tail.

This called for the creation of some new files and classes that can be found in the day-20's folder (since I'm not starting today in a new folder). Detecting the food and re-assigning it to a random spot inherited methods from the Turtle() class. We used that to create a new turtle and customized it to represent food. We created refresh method as well that moves the food to a random X & Y coordinate once the head of the snake was {number-value} away from it depending on what you set. The same thing goes for the scoreboard in which we created a new Turtle, but, had to dive into the docs again to alter it to work as a scoreboard. Finally, added the work to detect wall and tail collision to wrap up!

You can find the final project here -> https://github.com/kdleonard93/100-Days-Of-Code_Python/pull/12. If you want, clone the code from Day 20 and give the game a try yourself to see what high score your can get!

EOD

There's the game in all its glory! Gonna go ahead and find a way to throw this up on the App Store and start raking in secondary income 😂. But all jokes aside, creating this game was pretty fun, and was actually able to apply a bit of what I learned at work earlier today 😁.

If you want to keep up with my progress or just want to connect as peers, check out my social links below and give me a follow!

• 🐦 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn

For the following days (Day 20 and Day 21), the objective is the build the classic Snake game. Angela breaks down the goals for the and part one will consist of:

1. Creating the snake body by creating 3 squares on the screen last a given starting point.

2. Moving the snake forward without breaking.

3. Finally, add the ability to turn the snake.

There weren't any new concepts discussed in today's lesson, but, looking at Day 21, we touch base on Class Inheritance.

Making the Snake

This project has to be one of the hardest I've tried yet. More so on all the connected parts than the lack of understanding of certain concepts. We built the snake in our main.py file initially but then migrated the snake build into its own file and Class.

Snake Class:

class Snake:
    def __init__(self):
        self.full_snake = []
        self.create_snake()
        self.head = self.full_snake[0]

    def create_snake(self):
        for position in STARTING_POSITION:
            new_snake = Turtle(shape="square")
            new_snake.penup()
            new_snake.goto(position)
            self.full_snake.append(new_snake)

After getting it created, we worked on the movement. This part is where I struggled a bit due to needing to work with X and Y coordinates. Trying to get the 3 squares to align like a snake and then move smoothly took some more diving into the Python Turtle Graphics doc. After the snake got moving, we worked on adding the ability to turn it, which was a little bit easier to grasp and code up. After a couple of hours of early AM work, finished part 1! The snake moves forward and can turn without turning on itself.

Video: Snake Game Part 1 Example

Since I'm working on more than one file for this project, I won't be posting everything I wrote today but you can find it in the Day-19 folder on GitHub -> https://github.com/kdleonard93/100-Days-Of-Code_Python/tree/day-20/day-20

EOD

That wraps up Part 1 of the Snake Project. Since I worked on this before my normal work hours, there's a chance I'll be posting Part 2 (Day 21) later this evening. There I will make note of the new concept Class Inheritance and wrap up my first full Python game!

If you want to keep up with my progress or just want to connect as peers, check out my social links below and give me a follow!

• 🐦 Twitter

• 💻 Github

• 👾 Discord

• 👔 LinkedIn