DEV Community: Takahata Shintaro

HALLOWEEN FOLKLORE AI

Takahata Shintaro — Fri, 30 Oct 2026 23:44:25 +0000

_Introduction
_For Hacktoberfest Week 4, I built a minimalist, monochrome web application powered by Google Apps Script (GAS), the Wikipedia API, and Hugging Face’s Inference API.

The app allows users to input any keyword (e.g., "cats," "celt," "mirrors," or "harvest") to discover spooky Halloween folklore, myths, and historical traditions curated dynamically by AI and Wikipedia.

_Features & Highlights
_
Monochrome Minimalist UI: Designed with a high-contrast, clean typographic aesthetic (inspired by old literary archives) using custom CSS and Google Fonts (Shippori Mincho and Cinzel).

Google Apps Script (GAS) Backend: Serverless architecture handling API calls securely and managing server-side caching (CacheService) to optimize performance.

Wikipedia API Compliance: Fully adheres to Wikimedia’s User-Agent policy by passing a descriptive user agent and respecting data usage guidelines under CC BY-SA 4.0.

Hugging Face AI Integration: Connects to Hugging Face’s Inference API (Mistral-7B-Instruct) to synthesize and enrich Wikipedia search results with an eerie, atmospheric Halloween narrative (complete with a robust rule-based fallback if the API key isn't provided).

_Tech StackFrontend:
_
HTML5, CSS3, Vanilla JavaScript (Single-file template)
Backend: Google Apps Script (JavaScript)

APIs: Wikipedia Action API, Hugging Face Inference API

_Code Architecture
_

Backend (index.gs)
The GAS backend handles incoming requests, queries the Wikipedia API while strictly passing a compliant User-Agent header, processes the extracts through Hugging Face, and returns a structured JSON payload to the client.

Frontend (UI.html)
A clean, distraction-free search interface featuring asynchronous requests via google.script.run, smooth CSS animations, and direct links back to original Wikipedia articles for full reading compliance.

License & Acknowledgements
Built for Hacktoberfest.

Wikipedia data provided under the Creative Commons Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Meal finder

Takahata Shintaro — Sat, 24 Oct 2026 01:19:46 +0000

A Minimalist Recipe Finder Powered by TheMealDB API

Sometimes, deciding what to cook is harder than actually cooking.

There are so many recipes online, but finding something that matches what you're looking for can take time. I wanted to make that process a little simpler, so I built a small recipe recommendation website powered by TheMealDB API.

The idea is simple: enter a keyword, get recipe results, and spend less time searching.

🍽️ Try the Demo

Live Demo: [https://script.google.com/macros/s/AKfycbx_PN9JPc6yIV5UAesw77FHkh6aJJcd_9P-kAZDmxOGd9egmVLjy48iY5kcaQcZ7na0Nw/exec]

The interface is intentionally minimal, using a monochrome design to keep the focus on the search and its results.

✨ What Does It Do?

The website focuses on one straightforward interaction:

Enter a keyword in the input field.

Submit your search.

View the returned recipe results directly in the interface.

No complicated navigation is needed. The goal is to make recipe discovery feel direct and easy to understand.

🎨 Why a Monochrome UI?

I chose a simple black-and-white visual style because I wanted the interface to stay out of the way.

A minimal interface can help users focus on the task instead of navigating unnecessary visual elements. For a small utility like this, I think clarity matters more than adding features just for the sake of it.

🔌 Powered by TheMealDB

The project uses TheMealDB, a community-driven meal database that provides an API for recipe-related projects.

Using an existing API means I can focus on connecting the user's input to useful results and presenting the response in a readable interface, rather than building a recipe database from scratch.

It is also a practical way to explore how external APIs can turn a small web project into something people can actually use.

💡 What Problem Does It Solve?

This project targets a small but familiar problem: spending too much time looking for meal ideas.

Instead of manually browsing multiple recipe pages, users can start with a keyword and see the results in one place.

It is not intended to replace detailed meal-planning tools. It is a small experiment in making one everyday task a little easier.

🛠️ What I Learned

Building this project gave me an opportunity to work on the connection between user input, an external API, and the user interface.

It also reminded me that a useful project does not always need a complicated interface. Sometimes, a focused feature and a clear presentation are enough to make a tool worthwhile.

🚀 What's Next?

There are several directions I could explore in future iterations:

Improve the presentation of recipe results.

Make the interface more accessible and responsive.

Add more ways to discover meals, depending on the API's capabilities.

Explore how open-source AI could help users discover recipes in more flexible ways.

I'd like to keep the experience simple while making the results more useful.

🌍 Why Open Innovation Matters

Projects like this demonstrate the value of accessible developer tools and shared resources.

An API such as TheMealDB gives individual developers a way to experiment with real-world data without having to build an entire database first. That lowers the barrier to experimentation and makes it easier to turn an idea into a working prototype.

I believe open innovation is valuable because it allows developers to build on shared foundations, learn by creating, and gradually turn small ideas into useful tools.

🙌 Try It Out

Give the demo a try and let me know what you think!

What would make a simple recipe finder more useful to you?

I'd especially appreciate feedback on the interface, the search experience, and ideas for future improvements.

Thanks for reading!

plantsphoto: A Tiny Browser AI That Rewards You for Touching Grass

Takahata Shintaro — Mon, 12 Oct 2026 04:51:46 +0000

The image itself is passed directly to the local model in the browser. There is no image upload API, database, or server-side image processing.
The source code and deployment workflow are available on GitHub:
https://github.com/M-Taka-Shin/Touch-Grass
The site is deployed with GitHub Pages, and updates to the master branch are automatically deployed through GitHub Actions.
Why open innovation matters
This project would be much less useful if every image had to be sent to a remote service.
Using an open-source, browser-based machine-learning stack makes the core experience:

Private: photos stay in the browser during classification.
Affordable: there is no per-image API bill.
Inspectable: the model and application flow can be examined and modified.
Portable: the app is a static website that can run on a normal laptop or phone browser.
Replaceable: the classifier can be swapped for another model as the project evolves. The initial JavaScript and model files are loaded from a CDN, but the classification itself happens on the user's device. This is a useful middle ground for a small prototype: it is easy to share while keeping the actual image-processing step local. What I learned The most important lesson was that an AI feature does not need to dominate the product. MobileNet is not being used here to generate a long explanation or replace the user's judgment. It provides one small confirmation step, and the rest of the experience is about observing the world directly. I also learned that a simple local-first design changes the kind of product you can build. Without accounts, uploads, or a backend, the project became easier to understand and easier to trust. Limitations and next steps plantsphoto is intentionally small, and it has limitations:
The plant decision is based on the model's top predictions and a keyword list.
Some plants may be rejected if MobileNet uses an unexpected label.
Some non-plant objects may be accepted if their labels happen to match the keyword list.
The streak is stored only in the current browser.
The model still needs to be downloaded the first time the app is opened. Possible next steps include adding a more specialized plant model, improving accessibility, adding an optional offline cache, and letting users review their own plant-photo history without sending it to a server. For now, the app has one goal: make the next walk a little more interesting. Take a photo. Notice a leaf. Touch grass.