@Manenti

Future Me has officially started with a clean React 19 foundation using Vite, TypeScript, ESLint, and Tailwind CSS. The initial frontend architecture was organized around scalable folders such as app, pages, layouts, components, services, store, and the future-critical simulation domain. Global styling was also moved into Tailwind’s base layer, keeping the app dark by default while leaving the visual system flexible for upcoming futuristic interfaces.

The first simulation layer was introduced by defining the core domain types for life areas, scores, user input, scenarios, and timelines. We also added the first deterministic scoring utilities and an initial score calculator, turning lifestyle answers into structured life scores such as health, knowledge, finance, career, social, happiness, and discipline. This gives the project its first real simulation foundation without mixing business logic into the UI.

Project “Water Beep” is a time-based notification system designed to trigger three distinct buzzer pulses every 30 minutes. The development began with a circuit simulation in Tinkercad to validate electrical connections and logic, ensuring the buzzer operated correctly on Pin 8 before any physical components were handled.

The prototyping phase involved setting up the physical hardware on a breadboard, creating a stable ground bus, and finalizing the wiring. I then moved to the Arduino IDE, where I implemented a non-blocking timing solution using the millis() function instead of delay(), which keeps the system precise and responsive over long durations.

After uploading the code, I conducted rigorous testing to verify that the 30-minute interval remained consistent without temporal drift. The project successfully bridged the gap from virtual simulation to a functional, reliable physical device, serving as a robust foundation for future automation tasks.

Devlog: Fixing the Deployment

After submitting NihonGo!, I found out that Render was not an accepted deployment option for this project. I also realized that Render’s free tier can put services to sleep after periods of inactivity, which is not ideal for a project that reviewers and users need to test reliably.

To fix this, I migrated the deployment away from Render:

• Moved the frontend deployment to Vercel
• Moved the backend API deployment to Vercel
• Switched the production database to Neon PostgreSQL
• Updated the frontend environment variable to point to the new Vercel backend
• Updated the backend CORS settings to allow the new Vercel frontend URL
• Fixed the backend serverless deployment configuration for Vercel
• Added the PostgreSQL dialect module explicitly so Sequelize works correctly in Vercel’s serverless environment
• Re-ran the production migrations and seeders on the new database
• Tested account registration and the main app flow again after the migration

The main reason for this change was reliability. Since Render can make free services inactive when there is no traffic for a while, the app could appear broken or slow when someone tries to test it later. Moving the app to Vercel and Neon makes the project easier to access, test, and review.

The new deployment is now working correctly, with the frontend, backend, database, authentication, and CORS all connected again.

Atualizações

• Added pilot holes for heat-set inserts to improve alignment during installation.
• Added pass-through screw holes to the top case for M3 screws.
• Added four mounting holes to the PCB aligned with the case pillars.
• Rewrite the README

Since the last devlog, I focused on preparing NihonGo! for a more complete public release. I expanded the learning content with new seeders for more hiragana, katakana, N5 kanji, and beginner lessons covering particles like を, に, の, questions with か, and polite ます verbs. I also added backend tests with Jest and Supertest to validate the API health check, protected dashboard routes, and unknown route handling.

On the frontend, I repolished the landing page to better present the app as a full Japanese learning platform, with clearer calls to action, feature highlights, preview stats, and a stronger visual identity. I also added a custom favicon and included a preview GIF so the project feels more complete and presentable from the first visit.

Finally, I prepared the project for deployment: I configured the backend for production PostgreSQL over SSL, added the proper start/test scripts and dependencies, consolidated the documentation into a full project README, and published the live demo on Render at nihongo-udug.onrender.com. With this, NihonGo! now has content, documentation, tests, production configuration, and a working public deployment.

• Since the last devlog, I focused on making the dashboard more complete and data-driven. On the backend, I refactored the dashboard service and presenter, expanded the statistics service to return quick stats, daily goal progress, and recent activity, adjusted progress handling, added a migration for renamed character progress columns, cleaned up unused code, and updated the API docs.

• On the frontend, I connected the new dashboard data to polished cards for Daily Goal, Recent Activity, Recommended Lessons, and Quick Stats. I also improved module/exercise UI details, cleaned up duplicated or unused components, fixed naming and lint issues, and made small page-level adjustments across the app.

• I also expanded the Flashcards feature into a fuller management flow: fetching deck details, editing and deleting decks, editing and deleting cards, refreshing due cards and progress after actions, and resolving warnings around the page state. This makes flashcards feel much closer to a complete study tool rather than just a basic review screen.

Today I expanded NihonGo with new learning flows for practice and review. On the backend, I added the dashboard recommendation feature, connecting lesson progress, quick stats, and recommendations so users can continue unfinished lessons or start the next suggested lesson.

On the frontend, I improved the Dashboard with modular cards for continuing learning, daily goals, recent activity, recommendations, and quick stats. I also built the Kana/Kanji Trainer page with filters, progress tracking, random practice, answer submission, and instant feedback.

I also implemented the Flashcards experience, including deck creation, card creation, due-card review, answer reveal, and progress tracking. Finally, I cleaned up page exports/routes and fixed integration bugs across auth, exercises, module details, and flashcard behavior.

Since the last update, I shifted the backend toward a clearer screen-driven architecture by introducing dedicated screen services and presenters. This included the first lesson screen flow, with a new lesson endpoint and controller designed to return lesson content in a frontend-friendly shape. I also prepared the presentation layer to merge lesson data with user progress details, setting up cleaner contracts between API and UI.

I then expanded the dashboard API with a v2 response format focused on frontend consumption. The dashboard service now aggregates the user’s latest studied lesson plus quick stats in one place, and maps them into a structured payload for cards like Continue Learning, Lessons Completed, Exercise Accuracy, Characters Mastered, and Flashcards Reviewed. This makes the home experience more actionable and reduces data assembly work on the client side.

To support this, I improved backend organization by separating domain services from screen services and updating controllers to use the new structure. I also added supporting progress/statistics functions to centralize calculations and keep business logic out of route handlers. Overall, this sprint was about making the backend more scalable, consistent, and aligned with the next frontend iterations.

Since the last devlog, the app moved from a component-level state flow to a centralized app state using Context. This unified picture data, loading/error handling, selected date, favorites, and UI controls in one place, and the app is now wrapped with a global provider. A re-render issue was also addressed during this refactor, making the data flow more predictable.

The biggest feature additions were interaction-focused: users can now pick a specific APOD date, load a random APOD date, favorite items, and download the current image when available. Favorites are persisted in localStorage and surfaced through a dedicated drawer opened from the navbar, including a live favorites counter and quick navigation back to saved dates.

On the presentation side, the experience became more polished and informative. APODCard received animation and richer actions, and a new information panel with info cards was introduced to show metadata like media type, copyright, and HD availability. Overall, this phase focused on turning the project from a static viewer into a more interactive APOD exploration tool.

Since the last update, I moved the project further away from a simple single-screen APOD view and into a more structured interface. The biggest addition was the new APODCard component, which now renders the media, title, date, and explanation in a much more complete layout. It also handles both NASA images and videos, so the app can support whatever type of content the API returns.

I also added reusable UI pieces like Button and Container, which makes the codebase easier to scale and keeps spacing and actions consistent across the app. On top of that, Hero was simplified so it now just handles loading, error, and passing the fetched data into the card instead of containing all the presentation logic itself.

The main decision here was to split the UI into smaller components instead of growing one large hero section. That makes the project cleaner, easier to maintain, and ready for future features like date selection, richer interactions, and better content controls.

Since the last update, I moved the project from a basic APOD display into a more complete presentation layer. The main change was replacing the simple Hero output with a dedicated APODCard component that now handles both images and NASA videos, shows the title, date, and explanation, and gives the page a much stronger visual hierarchy.

I also added a reusable Button component so the action area feels consistent and easier to expand later. Along with that, I introduced a Container component to keep page spacing and width aligned across the app, which makes the layout cleaner and more maintainable as the project grows.

The biggest decision here was to organize the UI around reusable pieces instead of putting everything directly inside the Hero section. That made the code easier to read and set the project up for future features like date picking, richer interactions, and better content actions without turning the main page into a single large component.

So far, I’ve built the foundation of a React + Vite app that displays NASA’s Astronomy Picture of the Day. The project already has a custom space-themed visual identity, with a dark gradient background, branded navigation, and a simple page structure built around a main hero section.

The data flow is split cleanly between a service and a hook: nasaApi handles the request to NASA’s API, while useApod manages loading, error, and success states. The Hero component then renders the APOD title and image once the data is available, which keeps the UI logic simple and easy to extend later.

The main challenges so far have been organizing the code in a way that stays scalable and handling async API data safely from the start. I also made a deliberate decision to focus on a more intentional visual style instead of a plain starter-template look, so the app already feels like a distinct project rather than just boilerplate.

Since the last update, I pushed NihonGo! into the actual learning flow instead of just the dashboard. The modules page now pulls real progress data from the backend and presents each JLPT module as a clickable card, with loading, error, and empty states to make the experience feel complete and stable.

I also added dedicated module and lesson detail pages. Module pages now show overall completion and the full list of lessons, while lesson pages display the explanation content together with exercise previews, making the study journey feel much more structured. To keep everything consistent, I introduced reusable UI pieces like page headers, badges, empty states, and lesson/exercise cards.

I moved the front-end from setup mode into a real product experience by building the first complete dashboard screen for NihonGo!. The dashboard now loads live summary data from the API, greets the user, shows their current study progress, and highlights what they should continue next. I also added proper loading and error states so the page feels stable instead of empty.

To support that, I created a small set of reusable UI pieces like cards, stat blocks, and a progress bar, which made the interface much easier to structure and keep consistent. With that in place, the front-end now feels like the beginning of a full learning platform instead of just a shell around the authentication flow.

I started turning NihonGo! into a real frontend app by setting up the main routing structure and global providers for authentication and theme control. That gave the project a proper foundation, with protected routes for the learning area and a shared app layout that keeps navigation consistent across the site.

From there, I built the first visible pieces of the interface: a landing page, a styled auth layout, and a functional login screen. I also added reusable form components, API error handling, and session logic so the frontend can talk to the backend, keep users logged in, and send them to the dashboard when authentication succeeds.

Since the last update, I worked on the backend’s security and request-handling layer. I added validation schemas with Zod across the main routes, including auth, progress, trainer, and flashcards, so the API now validates params, query strings, and request bodies more consistently.

I also improved the app structure with a rate limiter, a not-found middleware, and stronger error handling for validation and database issues. On top of that, I added CORS configuration and request logging with Morgan in development.

This was also my first time using both Zod and Morgan, so this update was useful for learning how to structure validation and logging in a more organized way.