标签：#p

Have you ever been in a computer lab, classroom, or office where you needed to quickly send a file between your phone and laptop? I run into this problem all the time. Sometimes there's no USB cable, no pendrive, Bluetooth is painfully slow, or uploading to cloud storage just to download the file on another device feels unnecessary. So I decided to build SilentShare . What is SilentShare? SilentShare is a browser-based peer-to-peer file sharing application that lets you instantly share: 📁 Files (up to 50 MB) 💻 Code snippets 📝 Text 🖼️ Images No installation. No account. No server storing your files. Your data goes directly from one device to another using WebRTC . Whether you're sending files from your phone to your laptop, between classmates, or across the internet, SilentShare keeps the process simple. Why I Built It I wanted something that: Opens instantly in any browser Doesn't require creating an account Doesn't upload files to someone else's server Works on desktop and mobile Feels lightweight and fast Instead of relying on cloud storage, I wanted the browser itself to become the transfer tool. Features ✨ Peer-to-peer file transfer using WebRTC 📂 File sharing up to 50 MB (including ZIP files) 🔒 Optional end-to-end encrypted rooms using AES-GCM 📷 QR code invitations with built-in camera scanner 📊 Live progress, transfer speed, ETA, pause & resume 🖼️ Preview support for: Images Audio Video PDFs 💻 Share code snippets with syntax highlighting 👥 Multi-user rooms (around 5 participants) 🌙 Dark & Light mode 📱 Installable as a Progressive Web App (PWA) How It Works Create a room Receive a random room code Share the code, QR code, or invite link Other devices join Start sharing instantly The files are transferred directly between devices instead of passing through a storage server. Privacy One of the goals of SilentShare was privacy. No user accounts No cloud storage No permanent database Nothing stored after the browser tab closes If you set a room password, all transf

While we can build simple applications without using classes using PySide6, But in big applications and Massive coding systems We should use Classes But why? To understand why do we need classes in PySide6 We should first see the Python code First from PySide6.QtWidgets import QApplication , QWidget , QPushButton , QLineEdit import sys class MainWindow ( QWidget ): def __init__ ( self ): super (). __init__ () button1 = QPushButton ( " Button 1 " ) input = QLineEdit () if __name__ == " __main__ " : app = QApplication ( sys . argv ) window = MainWindow () window . show () app . exec () Before talking about why do we need Classes for PySide6 Let's Explain the code first line by line The imports first thing we make the imports we do need: from PySide6.QtWidgets import QApplication, QWidget, QPushButton, QLineEdit The QApplication Is the simply the application we will make, Like empty app on the RAM it do nothing but it's on the RAM if it's alone And the QWidget Is the Blank screen That will be placed on the Empty Application in the RAM The QPushButton Is like any button we are saying in any app Like the Subscribe button on YouTube or like Post button on Twitter QLineEdit is the input bar, Like the input bar of ChatGPT where you put on it your prompt or like The input bar in WhatsApp Where you type any thing on it to send it to your friends The class And finally The thing You clicked on the post for First thing we define the class How can we define it? Why do we need to define it? Why do even we want it? Who created it? (NOOO IAM JUST KIDDING) We can simply define the class in python by just typing class That's it just class then the name of it For Example MainWindow and then a little semi-colon : OR EVEN WE GIVE IT A Parents And Why do we need to define it, For simply use it BRILLIANT RIGHT? And we want the classes in PySide6 for give it a parents QWidget or even QMainWindow , And we will explain both of them right now but before it Let's explain first what does parents

submitted by /u/stronghup [link] [留言]

As developers, we all want AI to review our code. But sending proprietary, unreleased code to third-party cloud APIs (like OpenAI or Anthropic) isn't always an option—especially if you're working on client projects or under strict NDAs. I wanted an AI code reviewer that was 100% private , free , and actually understood the context of my entire project . So, I built one using Python and Ollama . Here’s a look at what it does and how you can use it! What it does It’s a CLI tool that uses local LLMs (like qwen2.5-coder or llama3 ) to review your code. No API keys, no subscriptions, and zero data leaves your machine. But I didn't want to just paste code snippets into a terminal. I wanted a tool that actually fits into a developer's workflow. Here is what it supports: 1. Review an Entire Codebase Just point it at your project folder. The app will recursively gather your files, automatically ignoring bulky folders like node_modules , .git , vendor , and .next , and give you a full architectural review. python3 app.py ./my-project/ 2. Review Pull Requests Automatically Want to review a PR? Just pass the GitHub PR URL. The tool auto-detects that it's a diff, fetches the changes, and switches into "PR Review Mode." Instead of looking at architecture, it zeroes in on the + lines to find bugs, edge cases, and missing tests introduced by the PR. python3 app.py https://github.com/facebook/react/pull/30000 (Working on a private repo? Just pipe it: gh pr diff 123 | python3 app.py ) 3. Pipe Anything Into It You can pipe individual files, diffs, or snippets straight from your terminal. cat src/main.py | python3 app.py 🛠️ How to run it yourself Install Ollama and pull a solid coding model: ollama pull qwen2.5-coder Clone the repo and install the requirements: pip install -r requirements.txt Run it! python3 app.py ./your-code 💡 The Magic Under the Hood The script dynamically switches its prompt based on what you feed it. If you give it a directory, it looks for separation of concerns

The AI hardware landscape has shifted significantly in 2026, with NVIDIA, AMD, and Intel all competing for developers who need GPUs capable of running local large language models and AI inference workloads. Choosing the right GPU for AI workloads requires looking beyond marketing numbers and focusing on the specifications that actually affect real-world performance. Memory capacity, memory bandwidth, and software ecosystem maturity consistently matter more than theoretical compute peaks when running transformer models locally. This comparison covers the most relevant workstation and prosumer GPUs available in mid-2026, including NVIDIA's Blackwell architecture (RTX 50-series), AMD's Radeon AI Pro R9700, and Intel's Arc Pro B70. The goal is to provide a practical reference for developers deciding which hardware best fits their model sizes, software stack, and budget constraints. Which GPU specifications matter for AI workloads Marketing materials from GPU vendors emphasise AI TOPS and tensor performance, but these metrics rarely tell the complete story for local inference. The specifications below are ranked by their actual impact on running large language models. VRAM capacity VRAM is typically the first limiting factor when running LLMs locally. A model cannot execute entirely on the GPU if it does not fit into available memory. Once model weights spill into system RAM, inference performance drops dramatically. Approximate VRAM requirements for common model sizes: Model Size Recommended VRAM 7B 8-12 GB 14B 16 GB 32B 24-32 GB 70B 48-64 GB 120B+ Multiple GPUs For most homelab users, moving from 16 GB to 32 GB of VRAM provides a substantially larger practical benefit than increasing raw compute performance. A 32 GB GPU capable of running an entire model will often outperform a theoretically faster 16 GB GPU forced to offload tensors into system memory. Memory bandwidth Memory bandwidth determines how quickly model weights can be streamed into compute units. Large tran

Your customers have stopped Googling "best note-taking app." They're asking ChatGPT, Perplexity, and Gemini instead — and getting back a short list of three or four products. If your brand isn't on that list, you're invisible, and unlike a Google ranking you can't even see where you stand. That's the problem I set out to measure. This post is the build breakdown: five AI answer engines, one uniform result shape, a mention-detection core that doesn't lie to you, and the honest gotchas I hit around cost and billing. The whole thing runs as a paid Apify Actor written in async Python. The niche has a name now — GEO (Generative Engine Optimization) or AEO (Answer Engine Optimization). Think SEO, but the search engine is a language model and the "ranking" is whether you get named in the answer. The core question Give the tool a brand, its competitors, and the buyer-intent questions your customers actually type: { "brand" : "Notion" , "competitors" : [ "Obsidian" , "Coda" , "Evernote" ], "prompts" : [ "best note taking app for students" , "Notion vs Obsidian which should I use" ], "engines" : [ "perplexity" , "chatgpt" , "gemini" , "claude" , "aiOverview" ], "samplesPerPrompt" : 3 } It asks each engine each prompt (several times, because LLM answers vary run-to-run), then analyzes every answer for: were you mentioned, how early, were you recommended or just listed, what's the sentiment, who else got named, and — the part incumbents skip — which domains each engine cited. That last one is the actionable output: it tells you which websites the AI trusts for your category, i.e. where you need coverage. Architecture: one shape to rule them all The trick that keeps the whole thing sane is that every engine adapter — whether it's a clean REST API or a messy HTML scrape — returns the exact same record shape : { " engine " : " perplexity " , " prompt " : " best note taking app for students " , " sampleIndex " : 1 , " responseText " : " ... " , " citations " : [{ " url " : " ... "

With the cash, the company aims to expand its world model offering and reach customers across geographies.

The company is raising at least $75 million, led by Robot Ventures, with significant participation from USV and other prominent investors.

Please read the 'How is this possible?' page, and the full interactive walkthrough to see how this is all done. Did you use AI? The site copy and explanations hand-edited by me pressing my keyboard buttons. I find AI writing to be cringeworthy and bland. However, AI did help a lot with churning out the code. It's definitely 'my code' - LLM-assisted, but not 'vibe-coded'. This is an entirely novel project and I don't think you could (or should) point an LLM at this and press 'Go' My full thoughts on the use of AI in this project are available to read here submitted by /u/Putrid-Bench5056 [link] [留言]

Bring on the magenta and peach.

My 2nd article this week, I'm supposed to keep it to just once per week but whateverrr, I've had this...

OnePlus and its parent company, Oppo, plan to announce in the coming days that OnePlus brand will be leaving the US and European markets, according to a machine translation of a WinFuture report. Should the exit actually happen, it will mark a conclusion to months of rumors about the future of OnePlus. Android Headlines said […]

Hey what's up guys👋🏻 Remember our last Perfect Circle challenge? We had some amazing attempts! While...

In the fast-moving world of cryptocurrency, market data changes every second — prices fluctuate, trades execute, and volumes shift continuously. Capturing this stream of real-time data and transforming it into meaningful insights requires a robust and scalable pipeline. In this project, I built a complete real-time crypto market data pipeline that captures, streams, stores, and visualizes live data from Binance using PostgreSQL, Debezium, Kafka, JDBC, and Grafana. The goal was to design an architecture that not only moves data instantly between systems but also keeps it queryable and monitorable in real time. What began as a simple Binance data extractor evolved into a production-grade CDC (Change Data Capture) workflow capable of detecting every database change, streaming it through Kafka, storing it in a sink database, and visualizing it live on Grafana dashboards.

Apple’s revamped Siri is more than a voice assistant; it’s now the backbone of the iPhone user experience. You can try it now through the iOS 27 public beta.

When an autonomous agent gets an email address of its own, the first question your security team asks isn't "can it send mail?" It's "can you prove, six months from now, exactly what it said and to whom?" That's a different problem from "does it work." A demo that fires off a few support replies looks great in a sprint review. But the moment a real customer says "your bot promised me a refund," or a regulator asks for the complete record of what an automated system told a data subject, you need a defensible trail — an immutable record of every outbound and inbound message the agent touched, captured outside the mailbox the agent can also delete from. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for. But the architectural point here is provider-agnostic and it's the part most "AI email" tutorials skip: the live mailbox is not your audit log. It's mutable, it has retention limits, and the same agent that sends mail can also trash it. If your only record of what the agent did lives in the inbox, you don't have an audit trail — you have a working copy. What "audit-log everything" actually means There are two stores in this design, and keeping them separate is the whole point. The live mailbox — the Agent Account grant. Messages flow in and out here. It's queryable, it's real-time, and it's mutable . Flags change, messages move folders, things get trashed. On the free plan it's also retention-limited: 30 days for the inbox, 7 days for spam. The audit store — your system. An append-only, write-once log keyed by message_id and thread_id . Nothing in it is ever updated or deleted in normal operation. This is the record you hand a reviewer. The audit store is the thing you build. Nylas gives you the two capture points — the send response and the inbound webhook — but the immutability is your responsibility. That means a WORM (write-once-read-many) object store, an append-only table with no UPDATE / DELETE grant for the app role, or a has

Rendering a big image on iOS is one of those things that looks trivial until your app gets killed by the OS mid-export. CGContext , draw, makeImage() , done — except the moment the output gets large, that innocent-looking pipeline quietly asks for gigabytes of RAM and iOS terminates you. I hit this wall building Mozary , an iOS app that packs 100+ photos into a single giant picture (a photo mosaic). In v1.1.0 I finally killed the "high-resolution export crashes with out-of-memory" bug for good. The fix: stop putting the canvas in RAM at all. Put it in a memory-mapped file and let the OS page it to disk. RAM usage dropped from "4.8 GB, please die" to a few dozen MB, flat, regardless of output size. This post is the walkthrough — with the actual Swift. If you've ever seen Core Graphics blow up on a big image (mosaics, collages, stitched panoramas, high-res rendering — same trap), this is for you. TL;DR A non-compressed bitmap costs 4 bytes/pixel . A 1.2-gigapixel image = ~4.8 GB of RAM just for the canvas. CGContext(data: nil, ...) allocates that in RAM. context.makeImage() then copies it again . Double death. Back the canvas with a memory-mapped file ( mmap ). Writes transparently page out to disk and don't count against your app's memory footprint . Wrap that same mapping in a CGImage via CGDataProvider — zero copy — and stream it straight to a JPEG on disk. Never call makeImage() . Decode source tiles at their draw size , not full size. Because you now spend disk instead of RAM: add a free-space pre-flight check and clean up temp files after a crash. Let's dig in. The problem: "compressed file size" is a lie about memory Mozary lays photos out on a grid. A typical high-res export is a 200 × 267 grid with each tile drawn at 150px : width: 200 × 150 = 30,000 px height: 267 × 150 = 40,050 px That's ~1.2 gigapixels . Here's the part people underestimate: the final JPEG is only a few hundred MB to ~2 GB because JPEG is compressed . But while you're drawing, the canvas i

Most multi-tenant SaaS apps that send email do it from one shared identity. There's a notifications@yourapp.com , every customer's mail flows through it, and the tenant is just a from_name you stamp on the subject line or a footer you swap out. That's fine until it isn't — until Tenant A's spam complaints drag down Tenant B's deliverability, until a reply from a customer lands in a single firehose inbox you now have to fan back out, until one tenant wants a stricter send cap than another and you realize you built none of that into the data model. So let's not share. Let's give every tenant its own real mailbox — a dedicated Agent Account per customer, each with its own grant_id , its own send identity, its own policy and limits, grouped into its own workspace. Not one inbox with a thousand label hacks. A thousand inboxes, isolated by construction. I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for when I'm wiring this up. Every step gets the two-angle tour: the raw curl call and the nylas command that does the same thing. Why per-tenant beats one shared sender The shared-sender model fails along a few predictable seams. Per-tenant Agent Accounts close each one: Deliverability blast radius. When everyone sends from one address, one tenant's bounce rate and spam complaints poison the reputation everyone shares. Per-tenant accounts — and, if you want, per-tenant domains — keep one customer's bad behavior from sinking the rest. Inbound that actually belongs to someone. A shared sender means replies come back to one mailbox and you're left correlating them to tenants by hand. When each tenant has its own grant, an inbound message.created event already carries the grant_id . The routing is done before your handler runs. Per-tenant policy and limits. Different customers, different rules. A trial tenant capped at a low daily send; an enterprise tenant with a higher quota and longer retention. With a shared sender you'd build all of that y

Most teams test email by not testing it. The send path gets a mock — expect(transport.send).toHaveBeenCalledWith(...) — and everyone agrees that's "good enough." The receive path gets skipped entirely, because there's no honest way to assert on a real inbox from a test runner. So the one part of your system that talks to the outside world over an unreliable, asynchronous, third-party channel is the part with the least coverage. That's backwards. The reason email is hard to test isn't the sending. It's the asserting . You can fire POST /messages/send all day, but to prove the message actually left, rendered correctly, and arrived with the body you expected, you need a real mailbox you control — one you can read programmatically and throw away when the run finishes. Shared Gmail test accounts almost get you there, but they bring OAuth on the runner, catch-all races between parallel workers, and a 90-day token that expires the night before a release. This post is about a different fixture: a disposable Agent Account created at the start of a CI run and deleted at the end. You mint a real mailbox per run (or per test), point your application at it, send and receive real mail, assert on the actual message body, and tear the whole thing down. No OAuth. No shared inbox. No leftover state. What an Agent Account gives you here An Agent Account is just a Nylas grant with a grant_id . That's the whole trick, and it's worth saying plainly because it's what makes this pattern cheap: an Agent Account works with every grant-scoped endpoint you already know — Messages, Drafts, Threads, Folders, Attachments, Webhooks. There's nothing new to learn on the data plane . If you've ever called GET /v3/grants/{grant_id}/messages , you already know how to read a test inbox. The difference from a normal grant is provisioning. A regular grant needs a real human to complete an OAuth flow. An Agent Account is created with a single API call — no OAuth screen, no refresh token, no human. It's a m

Most "AI email agent" demos quietly assume the agent answers everything. Point a model at the inbox, generate a reply, send it, repeat. That's a fine loop right up until the model hits a message it shouldn't touch — an angry customer, a legal question, a refund the agent has no authority to approve — and confidently fires off a reply anyway. The expensive failures in agent email aren't the threads the agent gets wrong. They're the threads the agent answers at all when it should have stepped back. So let's build the part that steps back. Not the classifier that decides a message is risky — that's triage , a separate problem. This is the handoff : once something flags a thread as "needs a human," how do you actually pull the whole conversation out of the agent's reach, park it where a person can find it, and make sure the agent keeps its hands off until that person clears it? I work on the Nylas CLI, so the terminal commands below are the exact ones I reach for when I wire up an escalation path. Every operation gets the two-angle tour: the raw curl call and the nylas command that does the same thing. What the handoff actually needs An Agent Account is, underneath, just a Nylas grant with a grant_id . That's the spine of everything here, and it's worth sitting with: there is nothing new to learn on the data plane. The same grant-scoped endpoints you already use — Messages, Threads, Folders, Drafts — work against this grant exactly the way they work against any Gmail or Microsoft grant you got through OAuth. So the escalation path isn't some special agent feature. It's three plain operations you already half-know: A place to put escalated threads. A custom folder — call it Needs human — that lives alongside the six system folders every Agent Account ships with ( inbox , sent , drafts , trash , junk , archive ). A way to move the whole thread there. Not one message — the thread . A reply is just the latest message in a conversation; a reviewer needs the full chain. A way