Show HN: Tablr – Supabase with AI Features https://ift.tt/ltABMro

Show HN: Tablr – Supabase with AI Features https://www.tablr.dev/ June 30, 2025 at 04:35AM

Show HN: Summle – A little maths Game https://ift.tt/pelw48M

Show HN: Summle – A little maths Game https://summle.net June 26, 2025 at 04:28PM

Show HN: Sharpe Ratio Calculation Tool https://ift.tt/JMkqalb

Show HN: Sharpe Ratio Calculation Tool I built a simple but effective Sharpe Ratio calculator that gives the full historical variation of it. Should I add other rations like Calmar and Sortino? https://ift.tt/YwTa9xX June 29, 2025 at 11:08PM

Show HN: Anti-Cluely – Detect virtual devices and cheating tools on exam systems https://ift.tt/sikVIqQ

Show HN: Anti-Cluely – Detect virtual devices and cheating tools on exam systems Anti-Cluely is a lightweight tool designed to detect common virtual environments, device emulators, and system manipulation tools often used to bypass or cheat in online exams. https://ift.tt/GedFhmN June 29, 2025 at 01:11AM

Show HN: Query your Rust codebase and generate types for anything https://ift.tt/LgQ4tDh

Show HN: Query your Rust codebase and generate types for anything Hello HN! As a long-time professional Rust developer. I've always been frustrated by the difficulty and "hackiness" of producing bindings to other languages, whether a frontend, an FFI library, etc. Not just in Rust but in any language. After many years of trying existing solutions and trying to make my own, I've finally developed a solution I'm very happy with. RTK (aka Rust Type Kit) allows you to write Lua scripts that perform queries on your code, such as method calls to Axum's `.route`, function definitions, and more, and then receive rich type information including all argument types, function paths, proc macro attributes, and more. Your Lua script can then read this information and emit an output file in any language of your choosing. Or, you can emit compiler errors and use it as a linter of sorts. You can even directly re-emit Rust code itself and use this as a richer proc macro solution! The code example is a bit verbose, so I encourage you to take a look at the repo's README. I look forward to hearing your thoughts, or any usecases you may come up with! https://ift.tt/qMOTg3f June 29, 2025 at 12:25AM

Show HN: A Go service that exposes a FIFO message queue in RAM https://ift.tt/WfkuE69

Show HN: A Go service that exposes a FIFO message queue in RAM https://ift.tt/o5qPZ6C June 25, 2025 at 05:04PM

Show HN: GPU market is absurd! So I built a dashboard of pricing/restock trends https://ift.tt/dYNbrXT

Show HN: GPU market is absurd! So I built a dashboard of pricing/restock trends Hey HN! This idea started with me not being able to buy a GPU and constantly losing to bots/scalpers. I figured I'd use this as way to see how far I can get with 'vibe-coding and designing'*. The end result was pretty far! Here are more details of behind the scenes. In a future blog post, I'll detail behind the scenes process of building this. - The landing page is React/Typescript/Tailwind.css (which I've never used before) - The dashboard is based on Evidence.dev - which is SQL queries in Markdown + little bit of custom Javascript for chart formatting (again never used before :) - Just being able to get an idea like this in my head into existence would have taken me many months of Stack overflow/Google research to first learn React/Typescript/Javascript but this took about a month (~1-2 hr a day) * 'Vibe-coded' is often a misnomer i.e. people sometime think it's a magic pill. From building this I can tell you that you can't just will the site into existence like a genie's wish. It still took significant effort to guide the LLM, debug when things go wrong, need to have an idea of design and taste of what to build and how to make it look good, work on many iterations. There were probably 500 iterations between the first and the final iteration. https://ift.tt/b9XURxi June 28, 2025 at 12:32AM

Show HN: I built Hispi, an app to design custom jewellery https://ift.tt/ctbV0Xi

Show HN: I built Hispi, an app to design custom jewellery Designing is free and gives you a breakdown of material choices and costs, then you can get a quote if you want to buy the ring. I'm working with around 50 jewellers in London and the UK's Jewellery Quarter but I think just designing a ring is pretty nice. https://hispi.app June 24, 2025 at 07:08PM

Show HN: Do You Know RGB? https://ift.tt/7Md3jpc

Show HN: Do You Know RGB? https://ift.tt/RTsHi0L June 24, 2025 at 01:49PM

Show HN: IssuePay – Get paid for open-source contributions https://ift.tt/83LBIKa

Show HN: IssuePay – Get paid for open-source contributions Hi HN! I’m Mario, and I’m about to launch IssuePay. Problem: Open-source contributors don’t get direct financial recognition for their work. Solution: IssuePay lets maintainers post bounties on GitHub/GitLab issues. Contributors pick tasks, merge code, and get paid automatically. You can then withdraw your earnings directly to your Bank Account. Try it out: https://issuepay.app Questions: Would love feedback on our UX, payout reliability, or any scaling tips. Note: Open to partnerships with OSS communities! Thank you, guys ! <3 https://issuepay.app June 28, 2025 at 12:01AM

Show HN: I built a JSON-RPC library for Zig with compile time reflection https://ift.tt/gyEKN3T

Show HN: I built a JSON-RPC library for Zig with compile time reflection Doing dynamic dispatching in a strict static typing language is hard. Something as simple as, map.put("add", add); map.put("hello", hello); fn add(a: i32, b: i32) i32 { return a + b; } fn hello() []const u8 { return "Hello World"; } is impossible because the value type of key/value of the map needs to be the same but all the function types are different. Calling functions with different number of parameters, different parameter types, and different return type dynamically is difficult. Other languages either use dynamic typing, runtime reflection, macro, or passing in one big generic parameter and let the function figure it out. In ZigJR, I use Zig's comptime feature to do compile time reflection to figure out a function's parameter types, return types, and return errors. I package them up into a specific call object and use the interface pattern to produce a uniformly typed object to be put into the map. It's not easy but doable. [1] [1] https://ift.tt/TZ5eXfg... https://ift.tt/SENLgf7 June 26, 2025 at 11:54PM

Show HN: Pocket2Linkding – Migrate from Mozilla Pocket to Linkding https://ift.tt/gUnI4KO

Show HN: Pocket2Linkding – Migrate from Mozilla Pocket to Linkding With the Mozilla Pocket shutdown coming up in about two weeks, I thought I'd share this quick tool to migrate to linkding in case it's helpful to others. After reviewing self-hosted options to Pocket, I decided linkding has the best combination of features. (The creator/author of linkding has done a great job -- however, I plan to eventually create a new tool that is based on linkding but adds some new features that the author has indicated he doesn't want to include [I’m currently using a fork, but I want to expand on it further].) HN thread about shutdown announcement: https://ift.tt/ijmJbZx Mozilla announcement: https://ift.tt/3jDOqT8 linkding: https://linkding.link/ Note that Pocket is shutting down July 8, 2025, but the export service will remain available until October 8, 2025. [edit] fix typo in title & formatting https://ift.tt/q8svX6u June 26, 2025 at 10:33PM

Show HN: Magnitude – open-source AI browser automation framework https://ift.tt/OPzl8bT

Show HN: Magnitude – open-source AI browser automation framework Hey HN, Anders and Tom here. We had a post about our AI test automation framework 2 months ago that got a decent amount of traction ( https://ift.tt/Q2Wy746 ). We got some great feedback from the community, with the most positive response being about our vision-first approach used in our browser agent. However, many wanted to use the underlying agent outside the testing domain. So today, we're releasing our fully featured AI browser automation framework. You can use it to automate tasks on the web, integrate between apps without APIs, extract data, test your web apps, or as a building block for your own browser agents. Traditionally, browser automation could only be done via the DOM, even though that’s not how humans use browsers. Most browser agents are still stuck in this paradigm. With a vision-first approach, we avoid relying on flaky DOM navigation and perform better on complex interactions found in a broad variety of sites, for example: - Drag and drop interactions - Data visualizations, charts, and tables - Legacy apps with nested iframes - Canvas and webGL-heavy sites (like design tools or photo editing) - Remote desktops streamed into the browser To interact accurately with the browser, we use visually grounded models to execute precise actions based on pixel coordinates. The model used by Magnitude must be smart enough to plan out actions but also able to execute them. Not many models are both smart *and* visually grounded. We highly recommend Claude Sonnet 4 for the best performance, but if you prefer open source, we also support Qwen-2.5-VL 72B. Most browser agents never make it to production. This is because of (1) the flaky DOM navigation mentioned above, but (2) the lack of control most browser agents offer. The dominant paradigm is you give the agent a high-level task + tools and hope for the best. This quickly falls apart for production automations that need to be reliable and specific. With Magnitude, you have fine-grained control over the agent with our `act()` and `extract()` syntax, and can mix it with your own code as needed. You also have full control of the prompts at both the action and agent level. ```ts // Magnitude can handle high-level tasks await agent.act('Create an issue', { // Optionally pass data that the agent will use where appropriate data: { title: 'Use Magnitude', description: 'Run "npx create-magnitude-app" and follow the instructions', }, }); // It can also handle low-level actions await agent.act('Drag "Use Magnitude" to the top of the in progress column'); // Intelligently extract data based on the DOM content matching a provided zod schema const tasks = await agent.extract( 'List in progress issues', z.array(z.object({ title: z.string(), description: z.string(), // Agent can extract existing data or new insights difficulty: z.number().describe('Rate the difficulty between 1-5') })), ); ``` We have a setup script that makes it trivial to get started with an example, just run "npx create-magnitude-app". We’d love to hear what you think! Repo: https://ift.tt/uahTk2P https://ift.tt/uahTk2P June 27, 2025 at 12:00AM

Show HN: MCP Server for Tally – Create and Manage Forms with Claude https://ift.tt/Du2zIoO

Show HN: MCP Server for Tally – Create and Manage Forms with Claude I've built an MCP server for Tally that bridges the gap between their complex API and simple natural language commands. As someone with ADHD, I built this because context-switching between documentation, form builders, and actual work destroys my flow. Now I can stay in one conversation and just describe what I need. The interesting technical challenges: 1. API Complexity Abstraction Tally's API requires deeply nested objects for simple fields. An email field needs ~10 nested objects with UUIDs. I built a translation layer so users can just say "add an email field" in natural language, and the server handles the complex structure behind the scenes. 2. Safe Bulk Operations For destructive operations, I implemented a preview-then-confirm pattern. The server generates a confirmation token during preview that must be passed back for execution. This prevents accidental mass deletions while keeping the conversation flow natural. 3. Smart Rate Limiting The server monitors API responses and adjusts its behavior dynamically. When hitting rate limits, it automatically reduces batch sizes and adds delays between requests. Added randomization to prevent multiple instances from hitting the API simultaneously. 4. Type Safety Throughout Full TypeScript with runtime validation for both MCP messages and Tally API responses. This caught several undocumented API quirks during development. Performance notes: - Batch creation of 100 forms: ~12 seconds with batched operations - Individual creation of 100 forms: ~5 minutes due to rate limits - Human creation of 100 forms: probably a full week of mind-numbing clicking - Submission analysis across 10K responses: ~3 seconds The code is ISC licensed: https://ift.tt/TEBUmrF This particularly helps when you need to create multiple similar forms but your brain rebels at repetitive tasks. Curious if others are building MCP servers and what workflows you're optimizing for. Also interested in thoughts on MCP vs traditional CLI tools. The conversational interface is slower for simple operations but much better for complex, multi-step tasks where you might forget the exact syntax. https://ift.tt/TEBUmrF June 26, 2025 at 02:24AM

Show HN: I rawdog a MCP server from scratch in Zig. No SDK https://ift.tt/jM6UpW5

Show HN: I rawdog a MCP server from scratch in Zig. No SDK Some time ago I wanted to write a MCP server in Zig but found out there's no real JSON-RPC support in Zig, which MCP needs for communication. I ended up developing a JSON-RPC 2.0 library in Zig and more [1], which had its challenges. So I finally was able to put together a MCP server in Zig. It's built from scratch implementing the protocol messages from the MCP JSON schema. It's actually quite magical to have the LLM calling my MCP server [2]. The work is not too bad. Most of the hard work has already been done in the JSON-RPC library. [1] https://ift.tt/xebsDRJ [2] https://ift.tt/Fm7u9DJ... https://ift.tt/jlwmk1Z June 25, 2025 at 11:44PM

Show HN: Autohive – Build AI agents the easy way for everyday teams https://ift.tt/2V719rJ

Show HN: Autohive – Build AI agents the easy way for everyday teams https://ift.tt/FtvhaP7 June 26, 2025 at 01:09AM

Show HN: PLJS – JavaScript for Postgres https://ift.tt/bgSOVZj

Show HN: PLJS – JavaScript for Postgres PLJS is a new, modern JavaScript trusted language extension, bundling QuickJS, a small and fast JavaScript runtime with Postgres, providing fast type conversion between Postgres and JavaScript, fast execution, and a very light footprint. Here are bencharks that show how it compares to PLV8: https://ift.tt/tYrjAlI This is the first step toward a truly light-weight, fast, and extensible JavaScript runtime embedded inside of Postgres. The initial roadmap has been published at https://ift.tt/Ds9JI5U You can join the discussion by joining the PLV8 Discord: https://ift.tt/dfL9We7 You can find PLJS at https://ift.tt/Vfioc2Y June 26, 2025 at 01:06AM

Show HN: Logcat.ai:AI-powered observability for Operating Systems(Android+Linux) https://ift.tt/W8b60Oz

Show HN: Logcat.ai:AI-powered observability for Operating Systems(Android+Linux) Hello HN! I'm an Android OS engineer. I've worked with AOSP and Linux kernels all my career and always wondered about lack of sophisticated tools to debug and analyze system-level logs. Always had to resort to manually skimming through large log files to find something I needed to. With the rise of LLMs and the AI-age, I felt it was a great opportunity to build something for OS engineers, which is what led to logcat.ai! We are building the industry-first observability platform for system level intelligence. Think "Datadog for operating systems" instead of applications. Currently, we support Android and Linux - more platforms on the way. With Android we offer: 1. logcat analysis: Ability to analyze logcat logs for root cause analysis of system issues with natural language search. Unlike, Firebase which is an app-level observability, logcat.ai provides intelligence at OS level spanning bootloader, kernel and framework layer. 2. bugreport analysis: As you know a bugreport is a super-verbose snapshot of an Android OS collected at a point of time. Analyzing these logs takes hours and sometimes even days. We are working to bring this down to minutes! Analysis of memory, cpu, process stats to infer memory pressure levels, system stress, and nail down the processes responsible for it, identify performance bottlenecks and memory leaks across the system. For Linux we offer: dmesg (kernel log) analysis to help identify issues at Linux kernel level. We plan to add support for different Linux distros with their own logging pretty soon. Our goal is to build a single-pane-of-glass observability experience for operating systems worldwide, something that's never been done before. Our website may not reflect all the features a.t.m but we have a lot of things cooking! Ask us anything. We are providing free beta access for a period of time. We'd love your feedback and comments on what you think about logcat.ai! https://logcat.ai June 24, 2025 at 10:53PM

Show HN: I built a tool to create App Screenshots https://ift.tt/YRBh2O3

Show HN: I built a tool to create App Screenshots I built a tool to create stunning App Store & Google Play Screenshots. https://ift.tt/pqAPHJo June 25, 2025 at 01:07AM

Show HN: Comparator - I built a free, open-source app to compare job offers https://ift.tt/4WPqNx6

Show HN: Comparator - I built a free, open-source app to compare job offers https://ift.tt/lzWGYP4 June 24, 2025 at 05:30AM