DEV Community: ronynn

On-Device Neural Networks for Predicting To-Dos in Karui

ronynn — Fri, 04 Apr 2025 04:41:00 +0000

https://github.com/ronynn/karui

A to-do list should be smarter, not just a dumb checklist. What if your app could predict your next task based on past behavior, time of day, and patterns? Instead of manually adding the same tasks over and over, Karui could learn from you and suggest what needs to be done.

Why On-Device AI?

Most AI-powered apps send data to the cloud, but:

Privacy: Keeping everything on-device means no data leaks.

Speed: Predictions happen in real-time without network delays.

Offline Support: AI still works without an internet connection.

How It Works: Using Brain.js for Neural Network Predictions

We can use Brain.js, a lightweight JavaScript neural network library, to train a model inside Karui, running entirely on the user’s device.

1. Training the Model

We collect patterns from past tasks, such as:

Time of Day (e.g., morning = “Check emails”)
Day of the Week (e.g., Monday = “Plan weekly goals”)
Task Frequency (e.g., “Workout” appears every 2 days)

The model is trained on these inputs:

const brain = require('brain.js');

const net = new brain.NeuralNetwork();

// Example training data (simplified)
net.train([
  { input: { morning: 1, workday: 1 }, output: { "Check Emails": 1 } },
  { input: { evening: 1, weekend: 1 }, output: { "Watch Netflix": 1 } }
]);

// Predict next task
const output = net.run({ morning: 1, workday: 1 });
console.log(output); // "Check Emails"

2. Running Predictions in Karui

Karui would pass the current time, day, and past tasks into the trained model. The app would then suggest tasks dynamically, adjusting to user habits.

If you always write code at 8 PM, Karui suggests “Code for 1 hour.”

If you skip workouts too often, Karui reminds you with a guilt trip.

If it’s Sunday night, Karui suggests “Plan next week’s tasks.”

The Future: Smarter Productivity, Minimalism Intact

Karui is built to be simple and efficient, but that doesn't mean it can't be smart. A lightweight, on-device neural network could make todo lists more intuitive, without bloat or privacy risks.

Would you use AI-powered task predictions in a minimalist app? Let me know!

Introducing HTML++ – The Future of Web Development

ronynn — Tue, 01 Apr 2025 00:20:00 +0000

HTML++: The First Full-Stack HTML Programming Language

For years, developers have been burdened by unnecessary complexities like JavaScript, Python, and even CSS. But what if I told you that HTML alone can do it all?

Welcome to HTML++, the first full-stack, AI-powered, blockchain-enabled, low-code-no-code programming language built entirely on <div> elements.

Why HTML++?

Zero Learning Curve: If you know <div>, you already know HTML++.
JavaScript-Free: No need for annoying scripts—just add data-ai="true" and let the browser handle it.
CSS on Steroids: We replaced CSS with <style type="ultra-css">, so now your animations compile to WebAssembly.
Backend-Free: With <meta server="true">, HTML++ automatically deploys itself to an ethically-sourced cloud server.

Features of HTML++

1. AI-Driven Code

Forget writing logic! Just describe what you want in a <describe> tag:

<describe>
  A todo list app with machine learning and dark mode.
</describe>

And boom—HTML++ generates it automatically.

Blockchain-Powered Forms

Every form submission is now stored on the blockchain for security.

<form data-blockchain="true">
  <input type="text" placeholder="Enter email" />
  <button>Submit</button>
</form>

No backend needed! Your data is now an NFT.

AI-Powered Debugging

HTML++ automatically fixes errors in real-time. If something breaks, just add:

<fix>
  Make it work.
</fix>

And the AI will regenerate your entire app.

Goodbye JavaScript. Hello, Sanity.

HTML++ is the only language you'll ever need. Get started today by upgrading your browser with our HTML++ compiler (a single 3GB extension).

HTML++: Because who needs logic when you have <div>?

Happy April Fools Day!!

Automating Android APK Builds with GitHub Actions (The Sane Way)

ronynn — Sun, 30 Mar 2025 20:19:00 +0000

Manually building and signing an APK every time you make a change? Nah, that’s a waste of time. The right way to do it is to automate the entire process using GitHub Actions. That way, every push or tag automatically triggers a clean, reproducible build.

Here’s how to set up GitHub Actions to build your Android APK (the sane way).

1. Create a .github/workflows/build.yml File

Inside your repo, make this directory and file:

.github/workflows/build.yml

Now, paste this inside:

name: Build Android APK

on:
  push:
    branches: [ main ]
  pull_request:
    branches: [ main ]

jobs:
  build:
    name: Build APK
    runs-on: ubuntu-latest

    steps:
      - name: Checkout repository
        uses: actions/checkout@v4

      - name: Set up JDK
        uses: actions/setup-java@v3
        with:
          distribution: 'temurin'
          java-version: '17'

      - name: Setup Gradle cache
        uses: gradle/gradle-build-action@v3

      - name: Build debug APK
        run: ./gradlew assembleDebug

      - name: Upload APK
        uses: actions/upload-artifact@v3
        with:
          name: Karui-APK
          path: app/build/outputs/apk/debug/app-debug.apk

This workflow:
✅ Runs on Ubuntu (clean environment)
✅ Uses Java 17 (modify if needed)
✅ Caches Gradle for faster builds
✅ Builds a debug APK
✅ Uploads the APK as an artifact (so you can download it)

2. Adding Signing for a Release APK

If you want to distribute a signed APK (for Play Store or F-Droid), modify the workflow:

Step 1: Store Your Keystore Securely

Convert your keystore to Base64 (so GitHub can store it as a secret):

base64 -w 0 my-release-key.jks > keystore.b64

Copy the contents of keystore.b64.
Go to GitHub → Your Repo → Settings → Secrets and variables → Actions → New Repository Secret
Add a new secret:

Name: ANDROID_KEYSTORE

Value: Paste the Base64 string

Step 2: Add Keystore Passwords as Secrets

Also add these secrets:

KEYSTORE_PASSWORD – Your keystore password

KEY_ALIAS – The alias of your key

KEY_PASSWORD – Your key’s password

Step 3: Modify build.yml to Sign the APK

Now update the workflow:

- name: Decode keystore
        run: echo "${{ secrets.ANDROID_KEYSTORE }}" | base64 -d > my-release-key.jks

      - name: Build release APK
        run: ./gradlew assembleRelease

      - name: Sign APK
        run: |
          jarsigner -verbose -sigalg SHA256withRSA -digestalg SHA-256 \
            -keystore my-release-key.jks -storepass ${{ secrets.KEYSTORE_PASSWORD }} \
            -keypass ${{ secrets.KEY_PASSWORD }} \
            app/build/outputs/apk/release/app-release-unsigned.apk ${{ secrets.KEY_ALIAS }}

      - name: Verify signature
        run: jarsigner -verify -verbose -certs app/build/outputs/apk/release/app-release-unsigned.apk

      - name: Align APK
        run: |
          $ANDROID_HOME/build-tools/34.0.0/zipalign -v 4 \
            app/build/outputs/apk/release/app-release-unsigned.apk \
            app/build/outputs/apk/release/app-release.apk

      - name: Upload Signed APK
        uses: actions/upload-artifact@v3
        with:
          name: Karui-Signed-APK
          path: app/build/outputs/apk/release/app-release.apk

This does:
✅ Decodes the keystore
✅ Builds a release APK
✅ Signs it using jarsigner
✅ Verifies the signature
✅ Aligns it (important for efficiency)
✅ Uploads the signed APK

3. Results

Now, every push to main will:

Build a debug APK (for testing)

Build & sign a release APK (ready for distribution)

No more "works on my machine" nonsense. Every build is clean and reproducible.

Check Out Karui

I built Karui using this exact setup. 84KB, Unix-inspired, and built the right way—minimal, efficient, and reproducible.

If you’re into simple, lightweight apps, give it a look. Maybe even steal my GitHub Actions workflow for your own projects!

Getting my app into IzzyOnDroid: Making It Fully Reproducible

ronynn — Sat, 29 Mar 2025 16:15:00 +0000

Getting Karui into the IzzyOnDroid F-Droid repo wasn’t just about submitting a link and calling it a day. F-Droid has strict rules, and I had to clean up my code to make it fully reproducible.

What’s Reproducibility?

A reproducible build means anyone can take my source code, compile it, and get the exact same APK—byte for byte. No weird dependencies, no environment-specific builds, just pure, verifiable software.

What I Had to Change

Removed dependency blocks – IzzyOnDroid (and F-Droid in general) doesn’t like anything that could introduce non-free dependencies. So, I stripped out anything unnecessary and ensured all dependencies were explicitly defined and open-source. These are blocks of encrypted code that is only readable by google, thus non-free.

No precompiled binaries – Everything had to be built from source, no sneaky prebuilt libraries.

GitHub Actions for signing – Instead of relying on a local build, I automated the process using GitHub Actions. This ensures every APK is built in a clean, controlled environment with my own signing key, making the process transparent.

Now, Karui is officially IzzyOnDroid-approved, meaning Android users can install and update it easily via F-Droid. Another step toward keeping software lightweight, efficient, and truly open.

If you haven’t checked it out yet, now’s the time!

https://github.com/ronynn/karui

Karui: My 84KB Unix-Inspired Android App Just Got GitHub’s Star Struck Badge!

ronynn — Fri, 28 Mar 2025 11:48:31 +0000

Yesterday was a big day—Karui, my ultra-lightweight Android to-do list app, just earned the GitHub Star Struck badge! If you don’t know, that’s what GitHub gives you when your project gets noticed by the community.

Karui is built for those who love simplicity, efficiency, and a bit of that Unix aesthetic. It’s a mix of System 24 CSS vibes (if you know, you know) and a touch of that old-school Windows Mobile design—clean lines, no fluff, just what you need. It’s only 84KB. No bloat, no ads, just a straight-up todo list that works.

The fact that people are noticing it? That’s wild. I built Karui because I wanted something fast and reliable, and now it’s getting love from others too. If you haven’t checked it out yet, it’s on GitHub—go give it a star if you like snappy, minimal, and Unix-inspired apps: https://github.com/ronynn/karui

What programming tools/frameworks do you think will stay relevant 15 years in the future?

ronynn — Tue, 11 Mar 2025 17:03:07 +0000

Alt Title: How do you know if a framework is worth sticking with?

I have been learning svelte for the past few days and have even started porting an alpine.js project to svelte. While svelte felt much easier than react, having studied some react for freecodecamp certificate, I can't quite call svelte easy by itself. And thus every once in a while I keep asking myself is it going to be worth it? Will I raise my skills enough to make really cool things or am I going to bow out whenever some concept feels slightly tough?

Ignoring my lack of perseverance, what frameworks do you think will be active enough in the next 15 years?

To avoid this question becoming a contested topic, I would like to clarify I got this question while looking at livescript's syntax, wondering why it never took off and became a dead language. Then wasted time at reading online discussions on why elm is no longer active anymore, and the split of ReScript from ReasonML, I learned about how people who get used to functional programming based languages always feel like all other languages are cavemen/primitive compared to its beauty. BASIC was a beginners learning tool to begin with, but why did pascal stopped being actively used?

I remember looking for a 3d renderer in 2018 or 2019 for a one off project, picked threejs but there was an overwhelming amount of choice of things to use, apart from unity engine and unreal most of those frameworks or engines are no longer even used anywhere (atleast in public repos), documentations take you to sold out domains (a github repo of docs could keep the tools usable atleast for tinkerers).

The kind of heights things like coffeescript and jquery were at one point compared to others is not even close to what we have now, which is good thing that we can design our things in a way that feels suitable to us, but If I have to port something that I wished to be something big, perhaps a decade long project, then it feels like a bad tooling choice from the start.

On a related note, the project that I am porting from alpine.js to svelte: Karui (just thrown in the src folder in the repo the app currently uses alpinejs). Alpine.js was great, but any typing mistake anywhere would break the whole thing without clear feedback, console.log was my only friend. Svelte's component based system felt brilliant but vite kept showing blank page every 3-4 minutes with no errors anywhere, I had to keep guessing the mistakes, and rerun pnpm run dev too many times. I see that as a vite problem, although would need to test more with other things. So my question isn't about vite (I am yet to understand that error), it's about gathering some general opinions on how does one pick a stack (language/ framework/ tooling) for longetivity?

For those who have worked in the field for some time, what signs do you look for to see if a framework has staying power?

Migrating my friend's HTML project to Rust + Dioxus

ronynn — Tue, 04 Mar 2025 12:03:18 +0000

I have a friend who after reading some blog posts and social media memes that rust is the future and what not used to keep suggesting anything I am making should be made in rust.

So this friend of mine recently started learning HTML and was making a simple personal page. I for some reason wanted to make a meme about how he should be using rust for this too. So I sat down and wrote this entire article, posted it on the issues section of his repo. We had a good laugh but I thought I would like to get more thoughts on this too from others.

Critical Concern for the Future of This Project

I just happened to stumble upon this repo and was immediately struck by something concerning. You’ve chosen HTML as the foundation for your personal page, this path is not sustainable long-term, this is a house of cards. If you don’t act now, I fear you will soon face crippling technical debt and, ultimately, a full-scale rewrite.

HTML simply doesn’t have the type safety, memory safety, or concurrency features necessary for a modern, production-grade personal webpage. Right now, sure, it might load quickly, and yes, it might be accessible to virtually every browser with minimal overhead—but at what cost?

Why Rust + Dioxus is the only sensible choice

While technically, benchmarks indicate that HTML and raw JavaScript are faster than Rust on the web, you have to remember that speed isn’t everything. Dioxus introduces valuable abstractions, Rust’s advanced memory management ensures that your <h1> tags and <p> elements are allocated the same level of architectural rigor as a distributed systems backend, or a aerospace control system.
Today, it’s “just” a personal page. But what happens when you need to scale? What if you decide to add a second page? Or ... a contact form? With HTML, you’d have to copy-paste code. With Rust, you can write robust, reusable components with compile-time safety. It’s a no-brainer.
Your current setup has zero protections against memory leaks, buffer overflows. Dioxus, leveraging Rust’s borrow checker, ensures that every <h1> tag and <p> element is safely allocated and deallocated. You never know when a mismanaged <div> might lead to catastrophic undefined behavior. Right now, your HTML is raw, unprotected, and vulnerable. Anyone could open DevTools and inspect your elements. This is a security risk. Rust’s borrow checker ensures that every <div> is allocated safely, and best of all—once compiled, nobody can modify your page without a complete recompile.
Concurrency – Your website may not be using threads now, but what happens when it needs to? Imagine multiple users visiting at the same time. Can your current setup guarantee data race safety? Rust can.

I have written a hello world program in Rust before, which I believe qualifies me to assist in this migration. Under your guidance, I’d be more than happy to contribute and help rewrite this entire project in a safer, more performant stack, your personal webpage will finally be in a production-ready state, capable of handling enterprise-level traffic without breaking a sweat.

You need to future proof your page against inevitable HTML deprecations.

Changed one line to make it funnier.

So what did you think of this? Don't tell me you actually agreed.