今日已更新 234 条资讯 | 累计 41008 条内容
关于我们

标签:#us

找到 1971 篇相关文章

AI 资讯

Powerful regression tests for your PostgreSQL project

Mark (aka Winsaucerer) here to show you how you can test your PostgreSQL database like a sorcerer. We are going to be using Spawn, a SQL build system supporting migrations and testing. You do not need to be using Spawn for migrations in order to use it for testing. Spawn does not require any extension installed. All you need is the spawn CLI and a psql connection to the database for Spawn to connect through. Spawn was built to solve some migration pains I've experienced, but I happily discovered that when used for testing, it is very powerful. To show you some of that power, we're going to use a contrived database example. It uses golden file testing to determine success. When the test runs, we capture the stdout and stderr output from psql, and compare that to expected output. Testing with Spawn involves these steps: Create a new test with spawn test new <name> and fill out the test steps Check test outputs with spawn test run <name> (or view the SQL that will be sent to psql via spawn test build <name> ) When outputs are as expected, create the golden file with spawn test expect <name> Run the test and compare to expected output with spawn test compare <name> For now, Spawn only supports connecting via psql, which means that you have access to all the features that psql provides. To get started, follow the Spawn install instructions: Install Spawn And then create a new folder on your system, and initialise a new project with a docker compose config ready for us to play with: # inside your new folder: spawn init --docker docker compose up -d You now have a running docker based PostgreSQL database and a spawn.toml file configured to connect to it. We are not assuming that you are using Spawn or any other tool for migrations, so you can manually create and update the database by connecting directly using psql: docker exec -ti postgres-db psql -U postgres Create the database ⚠️ Caution This post is not intended as an example of how to build an orders database. The des

2026-08-21 原文 →
开发者

Directus Basics Part 3 — User Roles & Permissions

This is part three of our Directus Basics series. In part one we set up our instance, and in part two we covered relationships between collections. Today we're covering access control — what determines who can see and touch your data. The Core Concepts Access control in Directus comes down to three terms: Permission — applies to one collection and one action (create, read, update, delete, or share). Can be full access, no access, or custom rules. Policy — a group of permissions bundled together, applied to users or roles. Role — defines a user's position within a project. A role can hold any number of policies, apply to any number of users, and have child roles of its own. What Happens Without a Role? If an administrator creates a user but doesn't assign a role, that user has valid login credentials but still can't access the Data Studio. Creating a role and assigning the user to it isn't enough either — logging in at that point returns a "No App Access" error. The missing piece is that the role has no access policy attached. The policy is what actually tells the role what its users can and can't do. The Access Order Access in Directus flows in a specific direction: Access Policy → Role → User In practice: define what level of access a user needs, build an access policy to match, create a role and attach that policy to it, then register the user and assign them to the role. Default Policies Every fresh Directus instance ships with two default policies: Administrator — the role you're signed in as by default, with unrestricted access to everything. Public — for data that should be visible without logging in. Think of a product catalog on an e-commerce site — forcing a login just to browse products is a poor experience. Rule of thumb: give the Public policy Read access only. Never Create, Update, or Delete. The public should be able to view data, never manipulate it. Giving a Collection Public Access Go to Settings → Access Policies → Public Under Permissions, click A

2026-08-21 原文 →
AI 资讯

On-Device Piano Autocomplete: A 125M Model That Actually Works

On-Device Piano Autocomplete: A 125M Model That Actually Works Meta Description: Discover how a 125M parameter model autocompletes piano music entirely on-device. We break down the tech, real-world performance, and what it means for musicians. TL;DR A developer shared on Hacker News that they trained a 125M parameter language model to autocomplete piano melodies — entirely on-device, with no internet connection required. The project demonstrates that compact, efficient AI models can deliver genuinely useful musical assistance without cloud dependency. This article breaks down how it works, who it's for, and whether it's worth your attention as a musician, developer, or AI enthusiast. Key Takeaways A 125M parameter model can run real-time piano autocomplete on consumer hardware without a cloud backend The model was trained on MIDI data and treats music generation similarly to how LLMs treat text prediction On-device inference means zero latency from network calls, full privacy, and offline usability This project sits at an exciting intersection of music technology, edge AI, and creative tools The approach has real limitations — it's not replacing a composer, but it's a genuinely useful creative assistant Similar techniques are being adopted in DAW plugins and music education software as of mid-2026 What Is "Show HN: I Trained a 125M Model to Autocomplete Piano On-Device"? If you spend time on Hacker News, you've probably seen "Show HN" posts — a dedicated space where builders share projects they've made. This particular submission caught significant attention: a developer trained a 125-million-parameter neural network to autocomplete piano music, and crucially, it runs entirely on your local device . No API calls. No subscription. No sending your musical ideas to a remote server. Just a model sitting on your machine, listening to what you play, and suggesting what might come next. The concept sounds deceptively simple, but the execution involves some genuinely clever

2026-08-21 原文 →
AI 资讯

The Rust vs. JavaScript Undefined Behavior Crisis: Lessons from Recent Security Incidents and Cross-Language Compilation Bugs

Originally published on tamiz.pro . The Silent Crisis: Undefined Behavior Across Language Boundaries Recent high-profile security incidents have exposed a growing concern in the software engineering world: undefined behavior (UB) is not just a C/C++ problem anymore. From Rust compilation bugs to JavaScript engine vulnerabilities, developers are witnessing how subtle language design choices can lead to catastrophic failures when code crosses language boundaries or interacts with low-level systems. These incidents aren't isolated — they represent a systemic issue affecting modern software stacks built on heterogeneous language ecosystems. Case Study: The Rust Memory Safety Myth Rust was built with the promise of memory safety without garbage collection. Yet, recent CVEs have revealed that undefined behavior in unsafe Rust blocks can compromise entire systems: The 2024 OpenSSL Rust Port Incident A critical vulnerability was discovered in a Rust port of OpenSSL where unsafe code blocks performed unchecked pointer arithmetic. While the safe Rust layer enforced bounds checking, the unsafe boundary passed raw pointers to the C layer without validation. // Vulnerable pattern discovered in the incident unsafe { let ptr = slice .as_mut_ptr (); // No bounds check - undefined if offset exceeds slice length let unsafe_slice = std :: slice :: from_raw_parts_mut ( ptr , len + offset ); } This wasn't caught by Rust's compiler because it explicitly allows unsafe operations. The UB only manifested during cross-language calls to the underlying C library. The WebAssembly Compilation Bug Another incident involved a Rust-to-Wasm compilation bug where the compiler optimized away what should have been defensive checks, assuming the guarantees of safe Rust would hold at runtime. When these assumptions broke at the Wasm boundary, attackers could trigger heap overflows. JavaScript's Hidden Undefined Behavior While JavaScript is often criticized for loose typing, its recent security incidents

2026-08-21 原文 →