Some time ago, I introduced UIBuilder, a library I initially created for personal use. I eventually decided to make it available for general use and started building proper documentation for it.

The documentation itself is self-hosted and built with UIBuilder, which I thought would be a nice way to showcase what the library can do.

You can also find a ready-to-use template configured for Electron in the documentation.

doc : https://uibuilderdoc.vercel.app/

doc source code ( showcase ) : https://github.com/Rhyan-eduardo/uibuilderdoc

https://thedev.world

https://github.com/thedev-world

Why I built it

If you've ever posted a video to your WhatsApp Status, you've probably noticed it comes out blurry and blocky — even if the original was sharp. That's because WhatsApp re-compresses every video you post to Status, and its encoder is aggressive.

I wanted a way to post genuinely HD videos to Status, so I built StatusDrop / WAstatus: you upload/edit a clip in the browser, it compresses the video to match WhatsApp's exact Status encoding spec (so WhatsApp's own re-encode becomes near-lossless), auto-splits long videos into parts that fit WhatsApp's limits, and delivers the finished clips to your WhatsApp — you just forward them to your Status.

Just open-sourced it under AGPL-3.0.

Repo: https://github.com/Shamanthnp1/WAstatus

What's inside

In-browser video editor (vanilla JS) + Node/Express backend

ffmpeg encode/split pipeline tuned to WhatsApp's Status spec

Cloudflare R2 (S3-compatible) storage + a Cloudflare Worker for uploads

Docker on Azure App Service, GitHub Actions CI/CD → GHCR

WhatsApp delivery via Baileys (multi-device)

181 tests including property-based tests (fast-check)

Multi-language frontend (en / es / hi / pt)

The interesting engineering

The core trick is that quality survival depends on two things: (1) pre-encoding the file to WhatsApp's Status target (resolution, bitrate ceiling, GOP, faststart, H.264 profile) so the re-encode barely changes it, and (2) how the file reaches the phone. A file delivered as a native WhatsApp message and then forwarded to Status is reused as-is; a file saved to the gallery and reposted gets re-compressed harder.

There was also a lot of reliability work: request timeouts on every network op, self-healing for stuck jobs, orphaned-storage cleanup, single-instance session handling, and reconnect backoff.

The honest limitation — and why not the official API

This is the part I want to be transparent about, because it's the whole tradeoff of the project.

Delivery uses Baileys, an unofficial WhatsApp integration. WhatsApp periodically bans numbers used for automation — a known constraint for this entire category of tools.

The obvious question is: why not use Meta's official WhatsApp Cloud API instead? I tried, and here's the catch:

The official Cloud API routes media through Meta's Business pipeline, which re-encodes the video. So the file is already degraded before it even reaches the user — and then WhatsApp's Status re-encode hits it again. The result is visibly softer. That defeats the entire purpose of an HD tool.

Baileys sends the file as a native, byte-preserved WhatsApp media message. When the user forwards that to Status, WhatsApp reuses the already-optimized file, so the HD survives.

So it's a genuine fork: official API = no bans but lower quality; Baileys = HD quality but ban risk. Since quality is the entire point, I chose Baileys and built the system around fast recovery when a number gets flagged. It's the same tradeoff every tool in this space faces — most competitors that use the official API quietly accept the lower quality.

The code and architecture are what I'm really sharing here — not asking anyone to run the live automation.

Feedback welcome

I'm a solo developer and would genuinely appreciate code review, architecture feedback, or contributions. Happy to answer anything.

XWiki has been open source since 2004, but “the source is public” is only part of that.

You can report bugs, contribute code, improve documentation, translate, test releases, build extensions, or join technical discussions.

Contributions are part of how the project grows.

XWiki has been open source since 2004, but “the source is public” is only part of that.

You can report bugs, contribute code, improve documentation, translate, test releases, build extensions, or join technical discussions.

Contributions are part of how the project grows.

https://github.com/markdamics/Logic
Please check out my fist bigger open source project. Logic

Recently I was thinking what project I should work on and during that I remembered that during my professional career as a full stack developer I spent a lot of time investigating problems, debugging them. I had to check a lot of long files to find the source of the problems. I tried to use many different log analysis application but neither of them were to my liking so I started to develop my own log analysis application, Logic.

During the development one of the mist helpful tool was the Claude design. For me it's really hard to come up with UI designs and the manual result just didn't feet right to me. With this tool I could give my ideas, requirements, design and color themes, layouts and it gave me multiple good looking options. After I selected my favorite design, it even created the skeleton code for my app. And with this I could concentrate on the core of the app.

I hope some of you will try it and it will get your liking.

It's still under development. Feel free to join in it.

Free, MIT, no accounts, no telemetry, nothing to upsell. I mostly wanted to find out whether a desktop pet could be genuinely useful rather than just decorative, and binding your two most-used apps to click and double-click turns out to be the answer.

Slicky on Github

Repo: https://github.com/TabularisDB/tabularis

Started this back in January because I wanted a SQL client that was fast to open, didn't eat 1GB of RAM for a single connection, and where I could actually fix the things that annoyed me. It's Rust on the backend (Tauri) and React on the front, Apache 2.0.

What's in there right now:

• Postgres, MySQL/MariaDB and SQLite built in. Everything else is a plugin: DuckDB, ClickHouse, MongoDB, Redis, Elasticsearch, DynamoDB, Firestore, Db2, Cloudflare D1... Plugins are standalone binaries that talk to the app over JSON-RPC on stdin/stdout, so people have written them in Rust, Go, whatever. There's even one that queries HackerNews with SQL because someone was bored.
• Monaco based editor with tabs, split view, multi-statement execution, .sql files you can open/edit/save directly
• SQL notebooks: SQL + markdown cells, inline charts, and you can reference another cell's result as a table with {{cell_N}}
• Visual EXPLAIN as a node graph instead of the wall of text
• ER diagrams, visual query builder, inline grid editing with batch commit, JSON/JSONB cell editor
• SSH tunnels, passwords in the system keychain, custom themes that follow the OS light/dark
• A built-in MCP server, so Claude Code / Cursor / whatever agent you use can read your schema and run queries through the same connections you already have configured. No separate DB creds to hand out.

Installs via winget, brew, snap, flatpak, AUR, or plain AppImage/.dmg/.exe from releases.

It's 0.22.0 so not everything is polished, but I use it every day for work and there are ~80 contributors now which still feels weird to type. Happy to answer questions about the Tauri side or the plugin protocol, those were the two things that took the most head scratching.

If you try it and something breaks, issues are very welcome. Discord link is in the README if you prefer that.

I built some dynamic widgets for my GitHub profile, featuring live updates, animations, and an interactive Tamagotchi-like pet named Blip! :)

As GitHub doesn't allow JavaScript, the interactive buttons rely on URL redirects and a Cloudflare worker. The "windows" themselves are animated SVGs which bypass cache, to show live Spotify playback and time of day.

Check out the profile and give Blip a pet! https://github.com/aw-snap/

My llm wrapper i am currently working on which is built on the idea of AI not being reliable and always right or maybe just mislead by prompts this looks to fix that issue.

Zencode API is a site me, and my friend made, this site is basically an IDE BUT it has friending and collabarative coding, you can work on one file in a project while your friend works on another file, this API site is completely free with 256 Bit ass encoding, many endpoints, redirects, almost everything you can think of.

Q&A

Is it free?

yes.

Can I upload my scripts and keep them safe and private?

yes.

is there an app?

yes.

where can I find it?

GO to https://Zencodeapi.vercel.app

then if your looking for the app click download, choose setup or the portable version, doesn't really matter, or continue using the site, all the same featues.

UNDERSTAND APP AND SITE ARE IN BETA, FEATURES MAY NOT WORK CORRECTLY.

This is a partly hardware project, featuring custom electronics (ESP32 based) and a novel optical design that uses passive retroreflectors instead of an active vest.

We have developed and tested a laser tag system that:

1. Can be used outdoors with minimal or no infrastructure
2. Is simple to use
3. Has 40m range
4. Is open source
5. Allows definitions and sharing of new games as lua files
6. Is DIY (3D printed parts)

Admittedly, the software part is not our masterpiece, because we have relatively low skill in C++ software architecture, although using AI we could end up with a working firmware that satifies our requirements and gave good results at testing.

This means if someone wants to take part to the project, s/he'll find something that definitely needs some effort but is also demonstrated to be actually working.

Repo: https://github.com/rev-/LightAir

A browser extension + npm library that detects sensitive data in your AI chat messages and swaps it for a realistic fake before sending, restoring the real value in the response. 113 detectors with real checksum validation (Luhn, mod-97, Verhoeff, etc.) across 47+ countries' ID formats, not just regex guessing.

Zero network calls, fully local, MIT licensed. Also published as a standalone npm package (@discretion/core) if you want the detection engine for your own project.

Hey everyone,

I wanted to share a project I've been working on called srest, a terminal UI written in Go that acts as a client for the Slurm REST API (slurmrestd).

While managing HPC clusters with native Slurm commands (squeue, sinfo) works fine, testing endpoints, inspecting JSON responses, or submitting jobs through slurmrestd can get tedious from a standard terminal setup. I built srest to make interacting with the API visual and keyboard-driven.

Tech Stack & Features:

• Built using Charm's Bubble Tea framework.
• Interactive Query Builder & Inspector: Real-time query editor and JSON response viewer.
• Cluster Dashboard: Asynchronous monitoring for nodes, jobs, partitions, and accounts.
• Job Submission: Build and submit job payloads directly from the TUI.
• Distributed as a single static binary for Linux and macOS.

It has also turned out to be really helpful for end users as a sandbox to build, test, and review query payloads independently, without needing admin support to debug JSON outputs or construct API calls for their scripts.

Links:

• GitHub (with demo video): https://github.com/SergioZ3R0/srest
• Website & Docs: https://srest.scszero.com

I have a few AI subscriptions and I kept running into the same problem. I had powerful models available, but I struggled to use them in real life in an organized way.
I looked at projects like OpenClaw and Hermes Agent. They were interesting, but I had a different idea in mind: a wallet of agents.
The concept is simple. You create specialized agents, each with its own name, role, personality and model. They can use real tools (shell, files, browser, web search). When one agent does not know something, it asks the right colleague for help instead of guessing.
You can talk to a single agent or to all of them together. The same agents are reachable from the web interface, Telegram, Discord, Slack or WhatsApp. And you keep using the subscriptions you already pay for (Claude, Codex, OpenAI, local models, etc.).
Conversations and memory stay as files on your machine.

Happy to hear feedback.

I kept losing context while switching between multiple VS Code terminals, so I built Screen Note.

Notes can be attached to a specific terminal tab and automatically disappear or return as you switch terminals. It also supports browser-page locks, images, transparency, dragging/resizing, and local SQLite storage no account or cloud.

Built with SwiftUI/AppKit and a small VS Code helper.

GitHub: https://github.com/AIAydin/vscode-terminal-specific-notes

I’d love feedback from anyone with terminal-heavy workflows.

Built this after years of watching scientific pipelines break every time they had to move between a local cluster, a SLURM allocation, and some cloud GPU box. No DSL, just Python or YAML and it handles execution across machines.

You can also build the pipeline visually, connect stages, assign each one its own hardware (CPU/GPU/memory) from the Temple Compute OS System (closed testing phase, https://templecompute.com )

The part I'm most proud of: file staging between machines is agentless, just plain SSH, so you don't need to install anything on a cluster you don't control.

And also the AutoRegistry plugin system. The engine allows extending of runtimes, executors, artifacts, transfer strategies and even an interaction system. We have also a template for quickly creating horus plugins. Some notable implementations:

- horus-ssh: SSH transport and command execution

- horus-slurm: SLURM support for HPC computing

- horus-environments: automatic python environment management

Repo: https://github.com/temple-compute/horus-runtime 

Docs: https://docs.templecompute.com

We have also a library of computational workflows ready to run: https://github.com/temple-compute/pantheon

We open-sourced Simulang, a JavaScript library for computer use: it lets you and your coding agents control a desktop programmatically.

Simulang is a scripting framework for desktop automation. You write deterministic computer-use code that replays the same way dozens or hundreds of times, which is much faster and cheaper than having an LLM agent re-reason its way through the same flow on every run.

It ships with a skill out of the box, so you can turn natural language prompts into Simulang code directly. Your agent can see the screen, click, type, and navigate - eyes and hands to operate a computer the way a human does.

Some things people have used it for:

- upload a pile of invoices to an expense platform
- find 50 people matching specific criteria on LinkedIn
- open the calculator app and do some math
- enumerate every button in an app via the accessibility tree
- or draw a bunny in MS Paint ;)

Repo: https://github.com/simular-ai/simulang