DEV Community: Fayaz Bin Salam

obsidotion: an Obsidian plugin that syncs your vault to Notion (and back)

Fayaz Bin Salam — Sat, 23 May 2026 22:11:05 +0000

two tools, same notes, constant copy-paste. that's what broke me.

i've been on both Obsidian and Notion for a while. Obsidian for thinking — local files, graph view, plugins. Notion for sharing — databases, team pages, linked views. The problem: they don't talk to each other, and manually keeping them in sync is a tax you pay every day.

so i built obsidotion — a free Obsidian plugin that handles both directions.

what it does

upload vault → Notion: takes every local markdown file and pushes it to a Notion database. Existing entries get overwritten.

download Notion → vault: pulls a full Notion database and writes it to your local vault. Same overwrite logic — what's remote wins.

works cross-platform: Windows, Mac, Linux, Android, iOS — wherever Obsidian runs.

the interesting design call

i went with full-overwrite semantics instead of merge/diff. less glamorous, but a partial merge that silently drops a note is worse than a predictable overwrite. at least you know exactly what happened.

the tradeoff: if you've edited the same note locally AND in Notion, one version wins and one dies. a future problem, but an honest one.

stack

TypeScript plugin using Obsidian's plugin API + Notion's official REST API. There's an optional .env config that auto-copies build output to your vault path during dev — saves a few steps per iteration.

install

download the zip from Releases, drop it into .obsidian/plugins/obsidotion/. Or build from source:

npm install
npm run build

obsidotion on GitHub

https://github.com/p32929/obsidotion

feedback welcome — especially if you have thoughts on incremental sync vs full overwrite. stars and forks appreciated.

open to building with sharp teams and solo founders — dms/email open.

I built LET — a local-first habit and life-events tracker in React Native

Fayaz Bin Salam — Fri, 22 May 2026 19:20:08 +0000

I've been building side projects for years. most of them live on github, quietly collecting dust. LET is one i actually use daily.

LET (Life Events Tracker) is a React Native + Expo app for tracking habits, mood, and life events — entirely offline, no account required, no data leaves your device.

the problem with most habit trackers

they want your data. subscriptions, cloud sync, accounts. i wanted something simpler: log what happened today, see patterns over time, own the data. so i built it.

the stack

piece	why
React Native + Expo	iOS, Android, and web from one codebase
NativeWind	TailwindCSS for RN — familiar syntax
Zustand	minimal state, no boilerplate
expo-sqlite + Drizzle ORM	type-safe local SQL, migrations run on device
Expo Router	file-based navigation like Next.js
Custom SVG charts	hand-rolled paths, no heavy chart lib

what it does

four main modes: daily habit tracking (with custom event colors), mood logging, life milestone recording, and a pattern view that surfaces weekly trends from those custom SVG charts.

data export/import is JSON, dark/light mode is fully supported, and swipe navigation works throughout.

the part worth talking about

this whole app was built through vibe-coding — describing features in natural language, iterating with AI, spending mental energy on product decisions instead of boilerplate.

it is not a toy. the codebase has proper navigation with expo-router, accessible UI atoms via rn-primitives, and a schema-first SQLite setup with Drizzle that runs migrations at startup. just built through a different workflow.

links

LET on GitHub

https://github.com/p32929/let

live web demo: https://p32929.github.io/let/

would love honest takes on what is missing or clunky. stars and forks appreciated if it is useful.

open to building with sharp teams and solo founders — dms and email open.

I built a React + Material-UI portfolio template — 198 forks later, here's how it works

Fayaz Bin Salam — Mon, 18 May 2026 14:40:49 +0000

i've been building android libraries, rust CLIs, electron apps — a lot of projects across a lot of stacks. the one that surprised me with its reach is a react portfolio template.

portfolio-v2 is the second iteration of my personal portfolio site. React, Material-UI v4, and Overmind for state management. it's at 198 stars on GitHub and i still get new forks showing up every few weeks, which tells me the problem it solves is real.

the problem

most portfolio templates are either too bare to look credible or too opinionated to customize without digging through the whole codebase. i wanted something that reads as complete — project grid, experience timeline, contact section, dark/light toggle — but where changing the content means editing one file, not hunting through JSX.

in portfolio-v2, that file is src/Others/GlobalVars.ts. your name, links, project list, work history — all of it lives there. edit the file, run two commands, done.

the stack

React + Material-UI v4 for the UI. the animated timeline, card grid, and theme toggle are all MUI components, tuned with a Nunito + Raleway font pairing that gives it a different feel from stock MUI apps without a custom design system.

Overmind handles global state (active theme, data). sounds like overkill for a static site, but it keeps the component tree clean as the content list grows, and makes adding new sections straightforward.

the non-obvious part: zero-config deploy

the whole thing deploys to GitHub Pages via react-gh-pages. npm run predeploy builds the bundle, npm run deploy pushes to the gh-pages branch. rename the forked repo to your-username.github.io and GitHub Pages picks it up automatically.

no Vercel account. no Netlify dashboard. no CI setup. for a portfolio you want to own permanently with zero hosting cost, that ends up mattering more than it seems.

fork it in 3 steps

fork portfolio-v2 on GitHub and rename it to your-username.github.io
edit src/Others/GlobalVars.ts with your data
npm run predeploy && npm run deploy

live demo: https://p32929.github.io/
repo: https://github.com/p32929/portfolio-v2

if you build something with it, drop the link in the comments — curious to see it. and if something's broken or worth improving, PRs are open.

open to building with sharp teams + solo founders — dms/email open.

I built the laziest Android SQLite wrapper — here's what I learned

Fayaz Bin Salam — Sun, 17 May 2026 00:29:23 +0000

android sqlite is genuinely painful. subclassing SQLiteOpenHelper, writing raw CREATE TABLE strings, managing ContentValues maps, handling cursors manually — it compounds fast. for a simple local database, there's a lot to wrangle.

i built EasiestSqlLibrary to cut through all that. the goal: the laziest possible API for SQLite on Android. init once, define your tables, do CRUD — no SQL strings required.

the problem

standard Android SQLite insert workflow: subclass SQLiteOpenHelper, write a CREATE TABLE constant, build a ContentValues object, call db.insert() with the right table name, handle nulls. that's just one insert. multiply by every table in your app.

EasiestSqlLibrary collapses all of that to a few method calls.

how to use it

Add to your project via JitPack:

implementation 'com.github.p32929:EasiestSqlLibrary:1.0.0.2'

Then init and go:

EasiestDB.init(context)
         .addTable("users")
         .addColumn("name", "TEXT")
         .addColumn("age", "INTEGER")
         .doneAddingTables();

// insert
EasiestDB.addDataInTable("users", new Datum("Alice"), new Datum(25));

// read all
List<List<Datum>> data = EasiestDB.getAllDataFrom("users");

// search by column value
List<List<Datum>> found = EasiestDB.searchInOneColumn("users", "name", "Alice");

one non-obvious thing

primary keys are automatic — every table gets an ID column without you defining it. this matters more than it sounds because manual ID management is where most beginners introduce subtle bugs: duplicate IDs, wrong autoincrement config, mismatched column indices.

the library also handles simple schema changes quietly during development, so you're not writing migration SQL every time you add a column while prototyping.

get it

EasiestSqlLibrary on GitHub

https://github.com/p32929/EasiestSqlLibrary

if this saves you some boilerplate, a star helps me know which projects to keep maintaining. honest takes and feedback welcome.

open to building with sharp teams and solo founders — dms open.

rotato: zero-dependency node proxy that rotates LLM API keys on 429

Fayaz Bin Salam — Sat, 16 May 2026 11:58:50 +0000

running multiple LLM providers — openai, gemini, groq, openrouter — and constantly hitting rate limits is annoying. i built rotato to solve exactly that.

it's a node.js proxy server that sits in front of your LLM API calls. when a 429 hits, it rotates to the next available key automatically. zero restarts, zero manual intervention, zero external npm dependencies.

what it does

point your existing code at localhost:8990/your-provider/ instead of the real API endpoint. rotato proxies the request, and if a key returns a 429 (or any status code you configure), it immediately retries with the next key in the pool.

the whole thing runs on node's built-in http module — no express, no axios, no nothing. clone, set two env vars, run.

features

any openai/gemini-compatible API — groq, openrouter, together.ai, anthropic, etc.
streaming (SSE) — full pass-through, no buffering
smart rotation — tracks recently failed keys, avoids them temporarily
live key validation — tests keys before saving
hot config — add, edit, disable providers/keys without restarting
per-key usage tracking — counts visible in admin panel
request log — last 100 requests with which key succeeded/failed
file logging — all requests to logs.jsonl with debounced batched writes

admin panel

dark/light themed UI at /admin. reorder keys for rotation priority, disable individual keys, generate pre-filled curl commands per provider.

telegram bot

wire up a bot token from the admin panel — chat with any configured model from telegram. text, image input, image generation — all routed through the proxy.

quick start

git clone https://github.com/p32929/rotato.git
cd rotato && cp .env.example .env
# set PORT and ADMIN_PASSWORD
npm start

open http://localhost:8990/admin, add providers, paste keys, done.

https://github.com/p32929/rotato — MIT licensed, 60 stars.

feedback welcome, especially if you've handled the same problem differently. stars/forks appreciated.

open to building with sharp teams and solo founders — dms/email open.

I built an unofficial Google Calendar desktop widget — works on Windows, Mac, and Linux

Fayaz Bin Salam — Fri, 15 May 2026 23:32:02 +0000

There's no official Google Calendar desktop app. If you want to check your schedule, you open a browser tab, navigate to calendar.google.com, and squint at whatever month it loaded last. Fine once. Annoying by the fifteenth time.

So I built google-calender-widget — an Electron app that puts your Google Calendar events in a proper desktop window. Runs on Windows, macOS, and Linux. Ships a system tray icon. Dark mode included.

How it works

The app authenticates via Google OAuth — log in once, and your events appear in a clean agenda view from then on. No browser tabs needed. A tray icon lets you open and close the window with a single click.

Stack is Electron + JavaScript. I wanted something that would actually run everywhere without distribution headaches. Electron handles that: one codebase, three platforms, binary installers for each. Latest release is v1.1.6 (September 2025).

One non-obvious detail

Getting Google OAuth working cleanly inside Electron is a small puzzle. The standard redirect-URI flow expects a web server to receive the callback — but there's no server in a native app. The fix is registering a custom URI protocol. The OAuth flow redirects to something like google-calendar-widget://auth/callback, and the Electron main process intercepts it. Small thing, but it's the difference between login that works and login that sort-of works with weird edge cases.

Get it

Source + binary releases: github.com/p32929/google-calender-widget

https://github.com/p32929/google-calender-widget

If you use it or spot a bug, open an issue. Stars help more people find it. Honest feedback welcome.

Always open to building interesting things with sharp teams and solo founders — DMs and email open.

AndroidAppLockscreen: drop a PIN lockscreen into any Android app in minutes

Fayaz Bin Salam — Fri, 15 May 2026 20:21:12 +0000

most android apps that need any kind of auth go straight to biometrics or firebase. fine — but what if you just need a simple PIN lockscreen? no backend, no cloud calls, just "enter your code to continue".

that's what AndroidAppLockscreen does.

i built it after copy-pasting the same lockscreen implementation across three different projects. the design is inspired by Diary — clean, minimal, nothing fancy.

what it handles

set password
check password on launch
change password
disable password
forgot password flow
customisable background color

setup

add the JitPack repo and one dependency:

implementation 'com.github.p32929:AndroidAppLockscreen:1.2'

extend your activities with LockscreenHandler, then in MainActivity's onCreate:

EasyLock.checkPassword(this);

first launch, no password set → does nothing. password set → blocks app until correct code is entered.

managing passwords after that:

EasyLock.setPassword(activity);
EasyLock.changePassword(activity);
EasyLock.disablePassword(activity);

the non-obvious part

the tricky bit wasn't the UI. it was activity lifecycle. you don't want the lockscreen triggering on screen rotation or when the user returns from a camera/file picker intent. LockscreenHandler handles all of that — it knows the difference between "user left the app" and "activity was recreated internally".

64 stars, 21 forks, MIT licensed.

repo: https://github.com/p32929/AndroidAppLockscreen

would love feedback, PRs, or stars if it saves you time. open to building with sharp teams and solo founders — dms open.

I built MacJuiceMonitor — a free macOS menu bar app for Bluetooth device battery levels

Fayaz Bin Salam — Tue, 12 May 2026 21:16:36 +0000

macOS doesn't make it easy to see how much juice is left in your AirPods, Magic Mouse, MX keyboard, PS5 controller, or any other Bluetooth peripheral. Some of it is buried in System Settings → Bluetooth, some of it never shows up at all, and most of the third-party tools that fix this are paid or come with analytics baked in. I wanted a tiny free thing that just worked, so I built MacJuiceMonitor.

what it does

A small Electron app that lives in the macOS menu bar and polls every connected Bluetooth device for its current battery percentage. AirPods, headphones, mice, keyboards, game controllers — anything that reports battery — shows up in a single dropdown, with the percentage right next to each device's name.

You can also pick one device whose battery the tray icon itself mirrors, so the number you actually care about (usually the AirPods, in my case) is visible at a glance without opening anything.

stack

Electron + TypeScript with electron-vite for the build pipeline
Polls macOS through system_profiler SPBluetoothDataType and parses the connected-devices section every few seconds
Renderer rebuilds the tray menu template from the latest snapshot on every tick

No analytics, no auto-update phoning home, no paywall. Clone, yarn build, ship to /Applications, done.

the one non-obvious bit

Electron tray menus flicker if you try to edit individual items in place every poll. The fix that actually works is the opposite of what feels efficient: rebuild the entire menu template every tick and assign the whole thing at once. macOS handles the swap atomically and there's zero visible flicker. The code looks wasteful, but the UX is buttery — and it's the same pattern other macOS menu-bar Electron tools use once you dig in.

links

MacJuiceMonitor on GitHub

plain url for crawlers: https://github.com/p32929/mac-juice-monitor

honest takes / stars / forks all welcome if it's useful. PRs especially — there are device types it doesn't recognise yet that someone with that hardware could add in 10 minutes.

open to building with sharp teams + solo founders — dms/email open.

i built a checkpoint system for claude code cli — here's how

Fayaz Bin Salam — Tue, 12 May 2026 12:20:01 +0000

claude code is great until you lose track of what it just did. you start a session, prompt your way through a refactor, accept changes, and an hour later you're staring at a working repo with no memory of which edit broke what or why you went down the path you did. cursor has checkpoints. claude code cli doesn't. that gap bugged me enough to build one.

the problem

the cli is fire-and-forget by design — it edits files, you accept, the conversation rolls on. if you want to ask "what did claude actually do in the last 30 minutes?" or "let me diff against where i was four prompts ago", there's nothing in the box. you can git commit between every prompt, but mid-session i almost never do, and the commit messages would be garbage anyway.

what ccheckpoints does

it's a tiny daemon that hooks into claude code's lifecycle:

on message submit → snapshot the workspace
on session end → close the checkpoint group
a background server on port 9271 keeps state
a web dashboard at localhost lets you browse sessions, jump between checkpoints, and see file-level diffs

basically: git, auto-committed at every prompt, scoped per session, no commit messages required. you can rewind to any point without polluting your real git history.

stack

typescript on node
sqlite for storage — 100% local, no cloud, no auth, no privacy story to write
claude code's native hook system instead of polling (way cleaner — the hooks fire exactly at the right moments)
the web ui is served from the daemon itself, so install + run is a single command

one non-obvious decision

i went back and forth on whether to store diffs or full file snapshots. diffs are smaller but they get fiddly with renames, deletes, and binary files. full snapshots cost more disk but they're trivial to navigate. for a tool that only ever runs locally, disk is cheap and "trivial to navigate" wins every time. ccheckpoints stores the file content per checkpoint and computes the diff on demand in the ui.

try it

npm install -g ccheckpoints
ccheckpoints

then run claude code normally — checkpoints appear in the dashboard automatically.

repo: github.com/p32929/ccheckpoints

https://github.com/p32929/ccheckpoints

would love feedback, especially edge cases where the hooks miss something (haven't found one yet but i'd like to know). stars + forks welcome if it's useful to you.

open to building with sharp teams + solo founders — dms/email open.

I built a clean Electron + React + Shadcn starter so I'd never have to wire it up from scratch again

Fayaz Bin Salam — Mon, 11 May 2026 19:53:00 +0000

Every time I sat down to start a new desktop app, the first hour was always the same boring dance. Bolt Vite onto Electron, wire React, sprinkle TypeScript, set up Tailwind, install Shadcn, then fight the build config until it stops crying.

Eventually I stopped re-doing it and extracted the parts that always have to be there into a starter. It's been sitting at ~80 stars on GitHub without much promotion, which suggests other folks were doing the same dance.

What's in the box

Electron + electron-forge + electron-vite — instant dev reload, one-command packaging for mac/win/linux
React + TypeScript
TailwindCSS + shadcn/ui — real components, not just primitives
usm-redux for state — lighter than redux-toolkit, less boilerplate than scaling vanilla zustand into a large app
Prettier + ESLint preconfigured so the linter shuts up day one

The non-obvious part

The bit that took the longest to settle was keeping the main process and the renderer process completely separate in the Vite config so HMR doesn't get confused when you touch a preload script. If you've ever had Vite quietly stop hot-reloading after you edited preload.ts, you know the exact bug. Once that clicked, everything else slotted in.

Commands you actually use

yarn          # install
yarn dev      # develop
yarn build:mac    # ship mac
yarn build:win    # ship windows
yarn build:linux  # ship linux

Repo

electron-shadcn-typescript on GitHub

https://github.com/p32929/electron-shadcn-typescript

If you've been stalling at the setup phase before building a desktop app — clone it, run it, build something. Would love stars / forks / issues if it saves you some setup time.

Open to collaborating with sharp teams and solo founders on real product work — DMs / email open at github.com/p32929.

Ollama Models Explorer — a clean Next.js UI to browse and filter local LLMs

Fayaz Bin Salam — Mon, 11 May 2026 11:34:06 +0000

If you're running local LLMs through Ollama, finding the right model is annoying. The official model page scrolls forever, capability tags are inconsistent, and there's no way to sort by context window or size without doing it in your head.

So I built Ollama Models Explorer — a small Next.js + Tailwind app that pulls the full Ollama model catalog and gives you a real, fast table. Search by name, filter by capability (chat, vision, embedding), sort by name, size, or context length by clicking the column header. Dark-themed because that's where I live.

Live demo: https://ollama-models-explorer.vercel.app/
Repo: https://github.com/p32929/ollama_models_explorer

Stack

Next.js (app router) + TypeScript
Tailwind CSS + shadcn/ui for the table and inputs
Lucide for icons
Model data loaded from a local JSON file, so the deploy is fully static and instant

One non-obvious thing

The capability filter ANDs the pills together instead of ORing them. Most "filter by tag" UIs default to OR ("any of these tags") which is almost never what you want when you're hunting for a model that does both vision AND chat. Small detail, surprisingly different feel.

Also: sorting context window numerically meant parsing strings like 128k, 1M, 32768 into a consistent unit before comparing. Looks trivial, but the Ollama catalog mixes formats freely.

Try it

It's bare-bones on purpose — would love feedback on what filters or columns you'd actually use day-to-day. Stars / forks welcome if it's useful.

Open to building with sharp teams + solo founders — DMs and email open.

— Fayaz (github.com/p32929)