标签：#dev

A SaaS team adds “Pay with crypto” to checkout. The first test looks fine: create a wallet address, show a QR code, receive USDT, mark the order as paid. Then production starts. One customer sends the right amount on the wrong network. Another pays after the invoice expires. A third sends 99.80 USDT instead of 100 USDT. Support sees a transaction hash but cannot find the order. Finance sees funds received but cannot match them to an invoice. The backend receives the same webhook twice and unlocks the product twice. That is the moment crypto payment integration stops being a QR-code feature and becomes a payment infrastructure problem. This is the first Dev.to post from Cryptoway . We build crypto payment infrastructure for online businesses, and here we will share practical notes about crypto payment API design, invoices, payment webhooks, stablecoin payments, checkout flows, reconciliation and payment status handling. What is a crypto payment gateway? A crypto payment gateway is the layer between a business event and a blockchain transaction. The business event can be: a SaaS subscription invoice; an e-commerce order; a digital product purchase; a marketplace deposit; a service payment link; an internal billing event. The blockchain transaction is the customer sending BTC, ETH, USDT, USDC or another supported digital asset. The gateway connects the two. It creates a payment request, shows the customer what to pay, monitors the blockchain, updates the payment status and notifies your backend when something changes. In other words: a crypto payment gateway is not the blockchain itself. It is the operational layer that makes blockchain-based payments usable inside real products. Crypto Payment Gateway vs Wallet Address A wallet address is enough for a manual payment. It is not enough for a product that needs order tracking, support visibility and finance reconciliation. Area Wallet address only Crypto payment gateway Order matching Manual matching by amount, address o

If you’ve ever worked with Arabic, Persian, Hebrew, Urdu, or any RTL (Right-to-Left) language on the web, you probably know the pain. Mixed RTL/LTR text rendering breaks unexpectedly. Punctuation looks wrong. Numbers don’t match the locale. Ellipsis appears on the wrong side. URLs inside Arabic text become unreadable. And emails or plain-text environments completely destroy formatting. After dealing with this problem repeatedly, I decided to build: rtl-text-tools A lightweight RTL text processing toolkit for JavaScript and TypeScript. It handles: RTL detection Direction normalization Arabic/Persian digit conversion RTL punctuation conversion Ellipsis fixing Unicode bidi wrapping CSS helpers DOM helpers And it works all the way back to IE11 with zero runtime dependencies. Why This Exists Most internationalization libraries focus on translations and formatting APIs. But very few actually solve the rendering problems of RTL text itself. For example: "مرحبا, رقم 123..." Visually, this often renders awkwardly in mixed-direction environments. You usually want: "...مرحبا، رقم ۱۲۳" That means: move ellipsis to the correct visual side convert punctuation convert digits preserve RTL readability That’s exactly what rtl-text-tools does. Installation npm install rtl-text-tools Quick Example import { fixRTL } from ' rtl-text-tools ' ; fixRTL ( ' مرحبا, رقم 123... ' ); // → "...مرحبا، رقم ۱۲۳" Arabic digits are also supported: fixRTL ( ' مرحبا, رقم 123... ' , { lang : ' arabic ' }); // → "...مرحبا، رقم ١٢٣" If the text isn’t RTL, it returns the original string unchanged: fixRTL ( ' Hello world ' ); // → "Hello world" Features 1. RTL Detection Detect whether text contains RTL scripts. import { hasRTL } from ' rtl-text-tools ' ; hasRTL ( ' مرحبا ' ); // true hasRTL ( ' שלום ' ); // true hasRTL ( ' Hello ' ); // false Supports: Arabic Hebrew Persian/Farsi Urdu Syriac Thaana N’Ko Samaritan Mandaic and more 2. Digit Conversion Convert Latin digits into locale-specific numerals. Persian

PixToCode is a new Figma plugin that turns the frames you've already designed into production-ready code with AI — React, Angular, Vue, or HTML, all Tailwind-first. Just published on the Figma Community: figma.com/community/plugin/1641790551381890223/pixtocode What it does Select one or more frames in Figma, pick a framework, click Generate. About 10 seconds later you have clean code that uses the exact colors, spacing, typography, and layout from your file — not generic Tailwind utility soup. Highlights: 4 frameworks — React (TypeScript), Angular (standalone + Signals), Vue 3, or semantic HTML5. All Tailwind-first. UI library presets — shadcn/ui, Material UI, Chakra, Ant Design on React, Angular Material on Angular. Output uses the real components , not generic divs. Refine with plain English — type "make the button rounded" or "use green for the active tab" and the AI rewrites the component in place. Multi-frame batch — select up to 5 frames, get them all in one pass. Variants → typed props — a Figma Component Set with Primary / Secondary / Disabled becomes one typed prop-driven component, not three duplicate files. Live browser preview — see the generated component rendered in a sandboxed tab before pasting it into your project. Cloud history — every generation saved to your account, synced across devices. How it works Get a free license key at pixtocode.com (5 free generations, no credit card). Install the plugin from the Figma Community. Paste the key into the plugin's license field. Select a frame, choose a framework, click Generate. Copy the code straight into your project. That's the whole flow. Pricing Free — 5 generations on signup Pro — $20/month for 100 generations Power — $39/month for 250 generations Team — $99/month, 5 seats, 600 shared generations (scales to 10 seats) All paid plans have a 7-day refund guarantee. Tips for best results Frames with auto-layout , named layers , and consistent design tokens produce the cleanest output. For huge dashboard

The test passed. The runbook completed. Infrastructure came back online inside the RTO window. None of that means the organization can recover from an actual disaster. Disaster recovery testing is designed to succeed. Clean environments, pre-staged dependencies, known failure modes, available staff — each design decision is operationally reasonable. Collectively they remove the conditions that make real recovery hard. What the test validates is test completion, not recovery capability. The Test Is Designed to Pass Every design decision in a standard DR test tilts toward a successful outcome. The test window is pre-announced, so the right engineers are available. The scope is pre-defined, so unexpected systems don't surface mid-exercise. The environment is either isolated or pre-staged, so competing failures don't complicate the recovery sequence. The data state is known and clean, so integrity issues don't slow the restore. The declaration point is assumed, so nobody has to make an ambiguous call under pressure. A test designed to remove the variables that make recovery hard cannot produce evidence about what happens when those variables are present. What Disaster Recovery Testing Actually Excludes Declaration threshold. In a DR test, recovery starts at a pre-agreed time. In a real incident, recovery starts when someone decides the situation has crossed the threshold for declaration — a decision that is rarely clean and routinely delayed 45 minutes to several hours. That delay is inside the real outage window and outside the test clock. Dependency assumptions. DR tests run against known, pre-cleared dependencies. Real incidents surface undocumented dependencies that were never in scope — a configuration service that hasn't been touched in two years, an authentication endpoint that wasn't in the architecture diagram. Data state. Test environments use clean or pre-staged data. Real recovery requires handling whatever state the data was in at the moment of failure — pa

This is a submission for the GitHub Finish-Up-A-Thon Challenge What I Built I started this project as a way to escape the noise of social media we have today and to focus on what matters. It was a personal project at first and I just wanted to get an uncluttered messaging working. After a while a few friends of mine started looking into it and liked the vision as well. Then I received a notification of the event and that excitement of finishing it up got all over me - I felt like a kid again. Demo Because I want to have control over my data, I self host the version on a small microcontroller, which is more than sufficient for me and my friends. To get a sneak peak at how it looks, check out this . (Be aware that this is not functional as there is no server connected) I made some demo accounts to give a sense of how the app looks and feels: The Comeback Story Because I had the messaging already working, I had to mainly implement the rest of the features, including enhanced profiles, networks and posts creation. Another thing I really had to work on was the design. Before, it was mainly a black and white testing ground - something every end user would be scared of. My Experience with GitHub Copilot I am really not talented in terms of designing a usable interface. However, my friends really didn't want to use a half-baked up command line application. Copilot really helped me achieve that polished look. Just to give a glimpse of how it feels, one friend of mine even described it as an enhancing feature when navigating through the tabs. Furthermore, although it mostly was bug free, "It worked, until it didn't". Sometimes I spent hours fixing or rather finding some annoying bugs. And because Copilot is a real expert in these languages, it was quite a moment when it guided me towards finding the mistakes I made.

After using Claude Code, Codex, and Pi Agent for months, I wondered: how many AI agents are on my machine? I built a scanner. Here's what it found: Framework Active Archived Claude Code 192 191 Codex CLI 37 0 Pi Agent 8 sub-agents 12 scripts MCP Servers 8 - Total 448+ The Waste Duplicate calls : Same prompt → 3 agents (8-18% waste) Overqualified models : Simple tasks on expensive models (15-25% waste) Cache fragmentation : No shared prompt cache (12-20% waste) Zombie agents : Archived still indexed (2-8% waste) → 30-50% of AI API spend is wasted. The Fix AMA — Agent Management Agent bash pip install ama-core && ama scan && ama start Scans all agents across frameworks Smart routing (simple task → cheap model) Lifecycle management Local dashboard at localhost:8765 Free calculator: ama-agent-store.vercel.app/calculator MIT licensed. Feedback welcome!

Hi all, I have a Windows Server 2026 box running IIS and am attempting setup a GitHub CI/CD pipeline. I am using a self hosted runner and that runner has been setup with minimum privileges to do it's thing. I have the following setup: - IIS points at a junction, - junction points at the build folder. -Project/ -live/ -> junction points at the live release -releases/ -v1/ -v2/ <- pointed at by live junction All is well in my workflow until a try to delete my old junction and recreate my new junction, pointing at the newly built version. It fails, I think because a IIS process still has a hold on the content of /live. Because the user account running the GitHub action runner is low privilege, it cannot stop IIS. I tried creating a scheduled task running as SYSTEM and manually triggering the task, but my low privilege user can't do that either. How have others overcome this? Any help greatly appreciated. I'm in a corporate environment so can't be lazy and give the action runner admin privileges. This has consumed my day. submitted by /u/Wotsits1984 [link] [留言]

As it happens every now and then, I've received another email from noreply at youtube.com asking me to fill in a form to audit my use cases of the YouTube API. I only have one project in the Google API Console, and the sole use case is to connect it to a Telegram bot I own that returns a query made by any user with access to the platform. However, in the email I received this time, they tell me that I manage shittons of projects with ID numbers that I am unaware of, and none of them correspond to the project ID that I actually manage. In fact, among the projects they claim I manage, there is one called "I do not remember" and other very strange names that I’ve never even heard of. The email is official and the form links to the same one they usually send me to fill in every few years. Anyone did receive recently some similar e-mail? Should I pay attention to this email, or have they completely lost the plot? submitted by /u/Felfa [link] [留言]

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

Many of you share great projects, but without a real use case. I want to encourage you that even in 2026 you can still achieve big things. You just need to find a niche and be fast. This website reached these values completely without advertising. Bewertiq.org It takes reviews and uses a mathematical regression model (OLS – Ordinary Least Squares) to estimate or refine ratings more accurately. By applying things like log-transformed features and category-based dummy variables , it tries to reduce noise and bias in raw user ratings and produce more stable, comparable results across different entities. On top of that analytical layer, the product positioning is: A trust-focused alternative to platforms like Kununu, Trustpilot, or Google Reviews Emphasizing no paid partnerships, no sponsored rankings, and no review manipulation or removal pressure Built around the idea of independent evaluation of companies using data instead of commercial influence submitted by /u/princessinsomnia [link] [留言]

Hey folks, just thought I'd share this here. I got an email recently(first one was automatically marked as spam) from Clera employee asking about "position at a certain company" and whether I'm interested. After 1-2 back and forth I realized that the emails are mainly AI-generated, but nevertheless gave it a chance and shared my CV, inviting for a live talk. After which I got an email from " talent@getclera.com " like this(picrelated). I never gave any consent to be signed up for a talent agent, never gave consent to store my CV or share it with an AI model. The reason I shared my CV was because email contained this phrasing: Here's what I'd suggest: if you can share your CV, the team will review it and take it from there. So, it was intended to be forwarded to the team in a mentioned company, not to store it in a talent pool for an AI agent. So, just reminding to check out the reviews online for email domains when you get invites to share CVs. Don't be like me. And for anyone else who experienced this: I'm not familiar with legal side of this, but if you wanna gather and do something about it, I might join (depending on whether I can since I'm not from US). P.S. This was raised once on r/theprimegen (found through search) but it didn't get much resonance. submitted by /u/Strict-Criticism7677 [link] [留言]

The DORA research programme is the most rigorous empirical study of software delivery performance ever conducted. Its four key metrics — Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore — have done more to give engineering organisations a common performance vocabulary than any other framework in the discipline's history. If you work in software and you have not read the State of DevOps Report, stop and read it before finishing this paragraph. Now: the DORA Four were derived primarily from organisations with cloud-native architectures, on-demand deployment infrastructure, and relatively unconstrained ability to release software when it is ready. The research cohort skews toward technology companies that have already made the cultural and architectural investments that make high-frequency, low-risk deployment possible. This is not a criticism of the research. It is an observation about its generalisability — and it has a specific consequence for practitioners who work in regulated enterprises: banks, healthcare systems, utilities, insurance carriers, government agencies. In these environments, the DORA Four are necessary but structurally insufficient. They measure the delivery pipeline accurately. They do not measure the operational sustainability of the team running that pipeline — and in regulated enterprises, operational sustainability is where SRE programmes go to die quietly, years before anyone realises the damage is permanent. This post proposes a fifth metric. Not to replace the DORA Four, but to complete them — to close the measurement gap that leaves regulated enterprise SRE teams flying blind on the dimension that most reliably predicts long-term programme failure. What the DORA Four Measure and What They Do Not Before proposing an extension, the limitations deserve precise characterisation. Imprecise criticism of a well-validated framework is noise. The limitations described here are structural — arising from the d

--- title : " Introducing rails-tenantify: Row-Level Multi-Tenancy for Rails 7+" published : true description : " A modern, safe, and robust row-level multi-tenancy gem for Ruby on Rails. Prevent data leaks, protect bulk writes, and preserve tenant context in background jobs." tags : rails, ruby, opensource, saas --- ## The Problem Every multi-tenant SaaS app eventually needs to answer the same questions: * How do we make sure School A never sees School B's data? * How do we scope every query to the right organization? * How do we keep tenant context alive in background jobs and Sidekiq retries? * How do we stop a careless `update_all` from wiping another tenant's rows? The typical answer is *"use acts_as_tenant"* or *"switch to Apartment."* But in modern Rails development, that often means: * Fighting unmaintained APIs on Rails 7+ * Losing tenant context when a background job retries * Dealing with schema-per-tenant complexity (Apartment) and heavy DevOps overhead * Rolling your own `default_scope` and crossing your fingers that nobody calls `unscoped` For most Rails apps, you just need **row-level tenancy** : one database, one `organization_id` column, and strict scoping. The pattern is simple. Getting it **safe** in production is not. --- ## What I Built **`rails-tenantify`** is a Ruby gem that adds row-level multi-tenancy directly to your Rails models and controllers. No external services, no extra databases per tenant—just your own PostgreSQL (or SQLite in dev). ruby class Project < ApplicationRecord include Tenantify::Scoped belongs_to_tenant :organization end ### Set the tenant once per request ruby class ApplicationController < ActionController::Base set_tenant_by :subdomain # acme.yourapp.com → Organization end ### Everything scopes automatically ruby Tenantify.current_tenant = current_organization Project.all # Only this org's projects Project.create!(name: "Q2 Roadmap") # organization_id is set automatically ### Switch context safely for admins or scripts

We've all been there. You're 45 minutes into a Docker tutorial, feeling great about yourself, and then someone casually drops: "Just pull the image and spin up a container." And you think: "...wait, aren't those the same thing?" First - this has happened to a good number of us if we are to be honest. Even almost every single DevOps engineer, cloud architect, and platform wizard you admire has typed the wrong term in a sentence at least once in their career. It's practically a rite of initiation. There should be a badge for it if you ask me. Why Does This Trip Everyone Up? Here's the sneaky truth: Docker commands blur the line constantly. You type docker run nginx and something called a "container" starts — but wait, didn't you just use an "image" called nginx ? Where did one end and the other begin? The confusion lives in the fact that they are deeply related — one literally gives birth to the other. But they are fundamentally, completely different things. Getting this distinction straight is your official rite of passage into DevOps. Once it clicks, the rest of Docker feels like cheating. Basically, A Docker Image is the blueprint : a frozen, static snapshot of everything your app needs - the OS layer, the dependencies, the config files, your actual code. It just sits there on disk, completely inert. You can't run a blueprint. A Docker Container is the house : the live, running instance that was built from that blueprint. It has processes running, files potentially being written, network ports being listened on. It's alive. And now, just like one blueprint can produce 10 identical houses on different streets - one Image can launch 10 identical Containers simultaneously; and that's where Docker's scaling magic comes from. # The image just sits here, unchanging docker pull nginx # Now we BUILD a house (container) from the blueprint docker run nginx # Build THREE houses from the same single blueprint docker run nginx docker run nginx docker run nginx Here is an exampl

This is a follow-up to SynaptoRoute: A Study in Local Semantic Routing . If you haven't read it, the short version is: SynaptoRoute is a zero-token semantic routing engine that classifies user queries into intents using local embeddings instead of LLM API calls. SynaptoRoute v0.3.0: Matching Semantic Router While Scaling to 50,000 Routes What Changed Since v0.2.0 When I published the first post, SynaptoRoute had just shipped dynamic batching and O(1) hot-reload. The throughput numbers were promising, but the accuracy story was incomplete. I had internal benchmarks but no comparison against a widely adopted baseline under identical, reproducible conditions. That gap is now closed. v0.3.0 is live on PyPI: pip install synaptoroute == 0.3.0 The Benchmarking Journey Getting to these numbers took multiple benchmark revisions. Early synthetic datasets produced catastrophic accuracy collapse and initially suggested that both SynaptoRoute and Semantic Router were performing poorly. After deeper investigation, the root cause turned out to be flaws in the dataset generation pipeline rather than limitations of the routing engines themselves. Several rounds of validation, failure analysis, threshold tuning, adversarial testing, and external benchmarking followed. All final results presented in this article come from independent public datasets with strict train/test separation, eliminating dataset leakage and benchmark inflation. That process was valuable because it forced the project to validate assumptions against real-world data instead of relying on synthetic benchmarks. The Benchmark That Actually Matters I evaluated SynaptoRoute against Semantic Router on two standard NLU datasets. Same embedding model ( BAAI/bge-small-en-v1.5 ). Same hardware. Same evaluation script. Same train/test splits loaded from HuggingFace. CLINC150 150 intents spanning 10 domains, plus an out-of-domain class. This is the standard stress test for intent routers. Metric SynaptoRoute Semantic Router

I made a website for my company and it was deployed on hostinger using wordpress a little over a month ago. About a week ago something went wrong and it started having so many problems. When I google the company name, and click on company's website it redirects me to some shopping website If I open the URL manually, it just opens a blank webpage, the source is also empty All the files are their in hostinger and all pages and details are visible in wordpress Somehow Google crawled over 800 URLs while my website only has about 25 pages and now when i google "site:companyname.com" all those weird URLs with Japanese name come up I tried fixing the site with hostinger AI, I myself looked a files and database for any mallicious activity, but I can up with nothing. Things work fine in localhost, and I tried creating a staging site with everything same at a subdomain that works fine too. If any one can help it would be great, I don't wanna loose this internship. I have not revealed the company name for my safety. submitted by /u/maybeamit [link] [留言]

I'm interested in building a new website for my business and am debating on whether or not I should hire a professional or design one by myself using AI. I've seen a lot of pretty nice sites built with AI tools like Claude, but I'm skeptical as to whether or not they are built appropriately. If anyone has opinions about the pros/cons of using an AI tool vs hiring someone I would appreciate hearing them. Thanks in advance! submitted by /u/HawgBandit [link] [留言]

There is a special kind of productivity theater that happens during a developer job search. You wake up motivated, open LinkedIn, and apply to 27 positions before breakfast. You press the Easy Apply button with the precision of a professional gamer. By the end of the week, you have submitted 143 applications, updated a spreadsheet with several impressive numbers, and developed a minor emotional dependency on refreshing your inbox. Unfortunately, your inbox still looks like an abandoned shopping mall. No interviews. No useful feedback. No clear explanation. Perhaps two automated emails thanking you for your interest before informing you that the company decided to “move forward with other candidates,” a sentence that has become the corporate version of disappearing into the fog. So you decide to solve the problem by applying to another 200 jobs. This is not a strategy. It is email-based agriculture. You are throwing resumes into the soil and waiting for a recruiter to grow. Volume Matters. Blind Volume Does Not. Let us begin with an uncomfortable truth: getting your first developer job usually requires applications. Sometimes it requires many applications. The market will not discover your GitHub profile through divine intervention. A recruiter is unlikely to wake up in the middle of the night with a mysterious urge to search for junior developers who recently deployed a to-do list. You need to put yourself in front of companies consistently. However, there is a significant difference between applying consistently while improving your positioning and clicking every blue button on LinkedIn until one of you collapses. Volume is useful when it generates information. Blind volume only produces exhaustion. If you apply to 300 jobs with the same generic resume, the same generic portfolio, and the same vague explanation of your skills, you are not running 300 experiments. You are repeating the same experiment 300 times and acting surprised when the result remains unchanged.

When I decided to ship this blog in four languages, I had a clear mental ranking. English would win on volume. Spanish would be runner-up because of the sheer speaker count. Japanese would stay steady because it's my native language. Portuguese, I figured, was the long tail. I added it mostly out of completism. Twenty-two days later, the GA4 snapshot disagrees with every part of that ranking. PT: 748 pageviews , 709 sessions EN: 195 pageviews , 176 sessions JA: 27 pageviews , 29 sessions ES: 7 pageviews , 7 sessions That is Portuguese pulling roughly 3.8× English, 28× Japanese, and 107× Spanish on the same blog, same publishing cadence, same author. One Portuguese article on its own (a post about a 24-hour security agent: 375 PV) got more pageviews than my entire English blog combined. I wrote that article hoping Spanish would surprise me. Instead Portuguese surprised me, and Spanish quietly continued to not exist. The setup, so you can discount my numbers properly This is not a clean comparative experiment. It's a single blog, kenimoto.dev , running four language directories ( /en/ , /ja/ , /pt/ , /es/ ). Articles get translated through a cross-language LLM pipeline, then hand-edited for register and locale (BR Portuguese vs PT Portuguese, LatAm-neutral Spanish vs Spain Spanish). The window: 2026-04-30 to 2026-05-21, 22 daily snapshots. EN has 26 articles. JA has 25. PT has 17. ES has 10. So PT has fewer articles than EN and still beats it almost 4 to 1. If you stop reading here, take this one thing: language asymmetry can swallow article-count asymmetry whole . Adding articles in a saturated language is slower than adding articles in an underserved one. Why Portuguese pulled ahead I don't think the answer is "Portuguese readers like me more." I think three asymmetries are stacking on top of each other. 1. TabNews is a community door English doesn't have TabNews is a Brazilian developer community where you can post a technical article and have it actually read by h

Take Aways Performance and Scalability : Pinecone is a managed machine-learning database that provides exceptional levels of performance and scaling capability due to its cloud-based design. Because of its distributed architecture and ability to do near-neighbor searches, Pinecone handles such tasks as similarity searching and anomaly detection on very large datasets efficiently. Easy to Integrate : One of the standout benefits of Pinecone is how easily it integrates through a high-level API and SDKs across several programming languages. This gives developers a real productivity boost by making vector storage, indexing and querying for machine learning applications far less complicated to implement. Strategic Factors : Pinecone brings advanced features and managed services that genuinely enhance machine learning workflows, though it does come with considerations like recurring costs and vendor lock-in. Organizations should think carefully about these factors alongside the benefits of streamlined database management and optimized performance before committing to adoption. The importance of storing and accessing information properly to build the best possible machine learning model really cannot be overstated. Pinecone addresses this directly by offering a Vector Database built specifically for ML queries, creating a strong opportunity to tap into the power of cloud databases. Designed from the ground up as a cloud-native application, Pinecone makes it straightforward to index and search complex, high-dimensional vector data — which in turn makes building state-of-the-art machine learning applications much more approachable and helps software development companies deliver more value to their clients through custom software development. What is Pinecone? Pinecone is a fully managed Vector Database that lets you store, index, and query complex vector data quickly and efficiently. Because of its vector-native design, the primary use cases for Pinecone fall within similar