DEV Community

discord banned my account of ten years over a cat gif, then it got deleted. i took the username back anyway.

this is the year i spent trying to get an answer out of discord, and how it ended. the account i've had my discord account since october 2015. it was my main, and it owned Akiko, my bot. i also had a separate personal account, kept apart on purpose. what happened in november 2025 my personal account was suspended under the graphic content policy. the reason was that i was a member of a server discord later removed. as far as i can tell, i joined that server for the custom emojis. the channel had been quiet for months. the only message i ever sent there was a cat gif, and other members had already posted the same ones. about a week later my main account was disabled for ban evasion. i got logged out instantly and never saw the DM, so i never had a chance to respond. the evasion charge only exists because the first ban exists. i didn't dodge anything, i just kept using the account i'd always used. the appeals i filed seven support tickets between november and march. every one got closed with the same canned reply: go to Settings, My Account, Standing, and let us know. one of them even got a human reply, and it was the same macro. the one real review request, the in-app one from the standing page, has been sitting at "you requested a review of this violation" for a year. no decision, no rejection, nothing. on november 6 i sent a data request to their privacy address, because that's the one channel that can't be bounced back to the standing page. it was acknowledged, and that's all i have so far. how it ended the personal account is gone. and as of today my main one shows up as deleted_user with a string of hex after it. a ten year old account, reduced to a placeholder. so there is nothing left to appeal. the thing i'd need reviewed no longer exists in their system. the funny part the username was free. i renamed the account i'm using now to motzumoto. it's not the account i lost, and none of the history came with it. but the name is mine again, and discord didn't get to keep that one. what it cost the bot mostly dodged it. i had moved Akiko to a dev team account long before the ban, so she's still here. the one thing that did get hit is her botlist listings, which sat under the banned account, so i can't edit any of them anymore. i've spent a year working around an account i can't open. if you run something on a discord account, make a team on everything that matters while you still can. I wasn't ever told this, but i did it anyway and im grateful for younger me :3

Powered by Readybot.io

DEV Community

Flutter + NVIDIA Edge AI: Model Versioning and Runtime Capability Negotiation

This advanced tutorial treats Flutter as the operator-facing presentation layer while wearable SDKs, Jetson services, ROS 2 nodes, and NVIDIA-accelerated inference handle device-specific or compute-heavy work. The goal is predictable latency, bounded memory, useful observability, and graceful degradation—not simply maximizing message throughput. Architecture note: Keep safety-critical control loops on the robot. A Flutter app is not a hard real-time controller and must not be the sole safety mechanism. 1. Define measurable service objectives Track freshness, event-to-display latency, throughput, frame pacing, CPU, memory, network use, battery, thermal state, dropped messages, reconnect time, and command acknowledgements. Do not use a single FPS number to represent the entire system: a smooth screen can still display stale data. 2. Instrument the complete path sensor capture
- > native/ROS processing
- > gateway publish
- > Flutter receive
- > state accepted
- > widget build
- > frame rendered
Record source and receive timestamps separately. Use monotonic clocks for elapsed durations within a process. When comparing devices, account for clock offset and uncertainty. Profile on a physical target in profile mode and inspect Flutter DevTools' Performance view. Debug-mode timing is not a reliable production baseline. See https://docs.flutter.dev/tools/devtools/performance 3. Establish a repeatable baseline Start from a clean launch. Connect to the robot or replay a fixed trace. Run a representative scenario for several minutes. Record frame times, memory, CPU, message rates, stale-data counts, and reconnects. Change one variable at a time. Compare p50, p95, and p99 latency, not just averages. class PipelineMetrics {
int received = 0;
int accepted = 0;
int dropped = 0;
int stale = 0;
int uiPublishes = 0;
}
Use bounded metric windows or histograms; do not store every sample forever. 4. Separate acquisition from presentation High-rate sources should not directly trigger widget rebuilds. Use a latest-value cache for state-like data, bounded queues for events that must be preserved, and a controlled presentation cadence. class LatestValue {
T? _value;
int _version = 0;

void put(T value) {
_value = value;
_version++;
}

T? get value => _value;
int get version => _version;
}
Replacing an older pending value may be acceptable for battery, pose, or temperature. Commands, alarms, and audit events need a separate reliable path and explicit acknowledgement semantics. 5. Make buffering bounded Every queue needs a maximum capacity, an overflow policy, a drop/replacement counter, and an owner responsible for recovery. Latest wins: pose, preview frames, current detections. Drop old items: display-oriented streams where freshness matters. Persist: events that must survive disconnection. Reject with feedback: commands that cannot safely be queued. An unbounded telemetry or log list turns overload into memory growth rather than a visible, measurable condition. 6. Protect the Flutter frame budget Keep parsing, filtering, and transformations out of build(). Split screens into independently updating sections and avoid rebuilding camera or map widgets for unrelated state changes. For CPU-heavy pure Dart work, benchmark compute or a dedicated isolate with realistic payload sizes. Isolates have startup and message-transfer costs. For hardware acceleration or platform APIs, prefer a native service designed for that workload. 7. Keep robotics compute near the robot Sensors -> ROS 2 / accelerated nodes -> Jetson gateway
|
compact UI-facing state
|
WebSocket / MQTT / gRPC
|
Flutter client
NVIDIA Isaac ROS provides accelerated, low-latency ROS 2 packages for Jetson and other NVIDIA platforms. Keep image processing, infe...

Powered by Readybot.io

DEV Community

Reference Edit Advanced: RGB + Depth Composite Reference in a Single Video Pass

Most reference-edit workflows use one reference. This one uses two simultaneously: an RGB reference for appearance and a depth reference for geometry. The combination unlocks doing four things in a single pass that normally need four passes. What the two references each carry RGB reference — who the character is. Face structure, hair, costume, colour. Depth reference — where everything is. Camera position, subject distance from lens, scene layout. Using both means the new character inherits appearance from one and spatial position from the other. Using only RGB, the character lands wherever the model feels like putting it. The four jobs in one pass Character replacement — the subject becomes the reference character. Action inheritance — the motion of the source performance transfers. Scene and camera preservation — because depth is conditioned, the camera does not wander and the set does not rebuild itself between frames. Audio-driven lip sync — when audio is supplied, mouth movement is driven by it. Doing these separately is how most pipelines end up with a character that has the right face but the wrong head angle, because each pass re-decides. Three variants File Use Standard Default settings Silent (无声版) No audio conditioning Face Refine Extra pass on the face after the main render The Face Refine variant is worth the extra time whenever the character is in frame larger than about a third of the image height. At smaller sizes the refine pass adds nothing. Where it breaks Depth conditioning is precise but rigid. If the source performance moves the subject closer to camera in a way the depth map does not describe (because the depth was extracted from a single frame), the composite drifts at that moment. The fix is a per-frame depth extraction, which is much more expensive — and the episode shows the difference. Files HF: https://huggingface.co/AI-KSK/minimax-h3-role-swap-reference-edit ModelScope: https://modelscope.cn/models/Sunjian520/minimax-h3-role-swap-reference-edit Video walkthrough (Chinese): https://youtu.be/UespHFT9cjc Bilibili: https://www.bilibili.com/video/BV1VjaD6jEU3/ Notes Three ComfyUI workflow exports; H3 weights and the depth extractor must exist locally. Tutorial material, not a product. Independent AI-KSK release; not affiliated with the model authors.

Powered by Readybot.io

DEV Community

Cognito session management: sign out devices with Lambda

Cognito session management answers a question that every app with a login hears sooner or later: “Where am I actually signed in, and how do I kick out that old tablet?” Until now, Amazon Cognito gave you two options: sign the user out everywhere at once, or build your own table of refresh tokens. Since November 11, 2026, Cognito can list the sessions of an account by itself and end them one at a time. I care about this because a “My devices” page is no longer a luxury. People who share an account, lose a phone or suspect misuse simply expect it. In this article you build that page with the Serverless Framework, TypeScript and two small Lambda functions for a fictional bike rental called “Speichenwerk”. On top, there is a support function your team can use to end suspicious sessions. In short With the new session management, Cognito lists every active sign-in of an account across devices and app clients and ends them individually, optionally together with linked sessions. You have to turn the feature on per user pool, and it requires the Essentials or Plus feature plan. The biggest pitfall: an access token that was already issued stays valid until it expires if your API only checks it locally. What you will learn in this article how SSO sessions and token sessions differ in Cognito how to build a “My devices” API with HTTP API, JWT authorizer and Lambda how support can end sessions, including linked sessions how to pick session limits and SSO validity per app client why short-lived access tokens matter after a sign-out What is Cognito session management? Cognito session management is an extension of user pools, the user directory in Amazon Cognito. Once it is on, Cognito keeps a server-side record for every sign-in: when it started, when it was last active, which device type it came from, which IP address and which city. New API calls let you read that list and end individual entries. Before, Cognito offered essentially two tools. RevokeToken revokes a refresh token the app still holds. GlobalSignOut signs the user out everywhere. The middle ground was missing: signing out one specific device whose tokens you never see. That is exactly the gap the feature fills. SSO sessions and token sessions Cognito knows two kinds of sessions. An SSO session is created when someone signs in through managed login, the sign-in page that Cognito hosts. It lives in a browser cookie and lets the user open other app clients of the same user pool without typing the password again. A token session is created on every sign-in to an app client and follows the lifecycle of the refresh token that client received. One detail helps a lot: a token refresh does not create a new session, it extends the existing one. Only a real new sign-in creates a new token session. If that sign-in came through an SSO session, the token session remembers its “parent” in the field OriginSessionId. One SSO session can carry several token sessions, a direct sign-in through the SDK has no SSO session. The sid claim in the token With session management turned on, Cognito adds a sid claim to ID and access tokens. A claim is a field inside the JSON Web Token (JWT). Its value stays the same across all refreshes of a session, so you can use it in logs or for your own checks. Watch out if you have a pre token generation trigger that sets its own sid: Cognito leaves your claim alone, and session management has no effect for the whole pool. Cognito session management compared to RevokeToken Before you build anything, it helps to put the tools side by side. The new calls do not replace the old ones, they cover different situations. Call Who calls it? What for? RevokeToken App with refresh token normal sign-out on the current device ListUserSessions User with access token show “My devices” RevokeUserSession User with access token sign out another device of your own AdminListUserSessions Backend with IAM permissions support view, suspected misuse AdminRevokeUserSession Backend with I...

Powered by Readybot.io

DEV Community

Last hours for $300 GCP Gemini credits, grab it if you haven't

Sorry guys, copying this quick breakdown from AI because there isn't much time left, grab it if you still haven't! Google is pulling Gemini platform (Vertex AI) out of the $300 Free Trial tomorrow (Nov 16) .) To keep it for the next 90 days, you have to sign up and click Upgrade to Paid today (Nov 15), then set a Spend Cap right after. I've got a regular VPS sitting around too and want to wire Gemini 4 into some cool open-source GitHub tools for small web utilities on techlift.solutions, instead of wasting the credits on basic chat prompts. Let me know if you already grabbed it, or tell me why it's not worth it?

Powered by Readybot.io

DEV Community

Your browser went quantum-safe two years ago. Your signatures are only now catching up

Your browser went quantum-safe two years ago. Your signatures are only now catching up Open any major website in a current browser and look at the handshake. There is a good chance the session key was agreed with X25519MLKEM768: a classical elliptic-curve exchange running next to ML-KEM-768, the lattice-based key encapsulation mechanism NIST standardized in FIPS 203. Nobody announced it with a banner. Chrome, Firefox, OpenSSL and OpenSSH just turned it on, and the internet kept working. That was the first half of the post-quantum migration, and it moved first for a simple reason. Key exchange is the part an attacker can exploit retroactively. Record encrypted traffic today, store it, and decrypt it years from now when a large enough quantum computer exists. That is the harvest now, decrypt later threat, and it is the reason NIST's final transition report, IR 8547, published on October 27, 2026, treats key exchange as the urgent half. The second half is signatures, and it is only now starting to ship in real software. Why signatures lagged behind A signature does a different job from a key exchange. It proves that a certificate, a token, a login, a passkey assertion or a software update really came from who it claims to come from. A forgery is only useful while the verifier still trusts the key, so there is no harvest now, decrypt later pressure on signatures. Nobody rushes to replace something that only breaks in the future. The real blocker was size. An Ed25519 signature is 64 bytes. An ML-DSA-65 signature is about 3.3 kilobytes, and its public key is close to 2 kilobytes. Put that in every certificate in a TLS chain, every JSON Web Token, every passkey assertion, and everything gets fat. Handshakes grow, tokens grow, and the protocols that carry them were never designed for signatures that big. That is why, two years after NIST finalized ML-DSA in FIPS 204, no browser-trusted certificate authority issues ML-DSA certificates yet, and no browser accepts one. The standards exist: RFC 9881, published in October 2025, defines ML-DSA in X.509 certificates, and RFC 9935, from March 2026, does the same for ML-KEM keys. The plumbing is there. The public trust part is not. What actually shipped this month On November 3, authentik, the open source identity provider, shipped version 2026.11, and it is the clearest example I have seen of the signature half moving from roadmap to release. It adds ML-DSA in three places: First, certificates. It can generate and store ML-DSA-44, ML-DSA-65 and ML-DSA-87 certificates next to the RSA, ECDSA and Ed25519 ones it already supports. These are for the parts you control: TLS between your own components, mutual TLS against a private certificate authority, and RADIUS with EAP-TLS 1.3. They are explicitly not for your public login page, because public CAs and browsers do not accept them yet. Second, OIDC tokens. OAuth2 providers can now sign ID tokens, access tokens and client assertions with an ML-DSA certificate, and the proxy outposts verify ML-DSA signed tokens from upstream identity providers. This is the part that puts actual logins onto post-quantum signatures. The honest catch, which authentik states plainly: applications that validate tokens themselves need a JWT library that understands ML-DSA before you switch a provider over. Check that first. Third, passkeys. WebAuthn registration and login accept ML-DSA credentials. No shipping authenticator supports ML-DSA yet, and some browsers error if you suggest an algorithm they do not know, so authentik puts ML-DSA at the bottom of the accepted list. Only an authenticator that offers nothing else will use it. That sounds useless until you think about it the other way: the support is in place and tested before the hardware shows up, instead of after. The same release raises the default symmetric encryption for SAML to AES-256-GCM. AES-128 is not broken by a quantum computer, but Grover's algorithm eats into its safety margin, and the NSA's CNSA 2...

Powered by Readybot.io

DEV Community

How I Built a Tsunami Simulator on Real Terrain with Mapbox and OpenStreetMap

Most disaster maps tell you where something did happen. I wanted one that answers a different question: what would happen on my street? So I built HazardSim: you click a coastline, pick a wave height, and watch the water move inland over real terrain. It also does sea level rise and meteor impacts, and there are pages for earthquakes, hurricanes and volcanoes too. This post is about how it works under the hood, and just as importantly, where it is wrong on purpose. The data Three public sources do most of the work: Elevation: Mapbox Terrain-RGB tiles, at roughly 10 to 30 m resolution. Each pixel encodes a height in its RGB channels. The documented decoding is: // Mapbox Terrain-RGB: height in metres
const height = -10000 + (R * 256 * 256 + G * 256 + B) * 0.1;
City boundaries: OpenStreetMap. When you click the map, the site finds the city under the cursor and outlines its real boundary. That polygon becomes the calculation area. Population: OSM tags, with a manual density slider as a fallback when a place has no data. The nice side effect of using real boundaries is that the output is not "a circle on a map". The flooded area respects the actual city limits. The physics (intentionally simple) I did not try to build a hydrodynamic solver. The rule is: Water enters from the sea. It floods every cell whose ground elevation is below the current water level. Every 250 m of travel, the wave loses 1 m of height. This one number stands in for friction against terrain and buildings. In pseudocode, the idea looks like this (a simplified illustration, not the production code): // BFS flood from the coastline
queue = coastCells.map(c => ({ cell: c, level: waveHeight }));
while (queue.length) {
const { cell, level } = queue.shift();
if (ground(cell) >= level) continue; // terrain blocks the water
flooded.add(cell);
const next = level - metresPerStep / 250; // lose 1 m per 250 m
for (const n of neighbours(cell)) {
if (!flooded.has(n) && next > 0) queue.push({ cell: n, level: next });
}
}
Hills, embankments and levees stop the wave, just as in reality. Water flows around obstacles and fills low ground, which is exactly what you want from a first-order tool. Sea level rise uses the same engine but without the decay: the water simply sits at the chosen mark everywhere it can reach. Meteors The meteor is a body of stone, iron, ice or loose rubble at a chosen entry speed (17 km/s by default). Damage radii come from standard overpressure scaling, and the crater is roughly twenty times wider than the body itself. Unlike tsunamis, meteors have no coastline restriction: you can drop one anywhere on Earth. One check I liked adding Tsunamis and sea level rise need a coast, so before calculating, the site checks for open sea within about 30 km of your click, using the same elevation data. If there is none, it tells you instead of producing nonsense. What it gets wrong (on purpose) This is the part I care about most. The output is an order of magnitude, not a forecast: A real tsunami depends on seafloor shape, the fault that moved, the tide and the time of day. The tool ignores all of that. It answers: if water of this height arrived here, how far inland would the terrain let it go? Casualty numbers assume nobody evacuated, which never happens in real life. The decay rule is a single constant, not a fluid simulation. I would rather ship a simple model with honest labels than a flashy one that looks authoritative. What I learned The same wave height gives wildly different results depending on only a few metres of elevation. A 10 m wave barely troubles a city on high ground, while flat deltas are devastated. Seeing that on a map is more convincing than any table. What is next Earthquake, hurricane and volcano pages exist, and I recently added an ice age map showing the ocean 130 m lower than today. There is also an Android app on Google Play. If you try it, I would love feedback, especially on the model and on places wher...

Powered by Readybot.io

DEV Community

Product Compositing: Dissolving a Product Into a Scene, Then Finishing It as a Hero Shot

Pasting a product into a scene is easy. Making it look like it belongs there — correct contact shadow, colour bounce from the environment, and a plausible edge where the product meets the surface — is the part that takes an afternoon. This episode splits that into two jobs and gives each its own model. The two workflows # Workflow Job 01 Qwen Image 2.1 product-scene dissolve, 40-step quality + Viggle accelerated Compose the product into the scene 02 H3 VDN 12NFE high-quality second pass Finish it as a hero shot The split matters: composition and finish are different problems and a single model doing both ends up mediocre at each. What "dissolve" means here Not alpha compositing. The model re-renders the product in the scene context — which means it reconstructs the lighting on the product from the scene, adds contact shadow at the base, and lets environment colour spill onto adjacent surfaces. That is why the result reads as cohesive. It is also why the product's exact label text and logo placement drift — the model is reconstructing, not copying. The 40-step vs Viggle trade 40-step quality — label text stays legible, material reads correctly (glass reads as glass, fabric as fabric). Slow, used for the final frame. Viggle accelerated — fast enough to iterate on composition. Label text degrades first, then fine surface detail. Use the accelerated path to decide the composition, then re-run the same seed at 40 steps for the frame you actually keep. The Hero Shot pass The H3 VDN 12NFE pass takes the composited frame and re-renders it at higher fidelity. Its job is not composition — it is making the product read as a photograph rather than a composite: micro-edges, specular highlights, depth-of-field fall-off. 12 NFE is the operating point where that finish is convincing without costing a full render. Where this fits commercially E-commerce hero images without a product shoot. Seasonal variants: one product, many scenes, consistent finish. A/B testing backgrounds before committing to photography. The honest limitation: if the product has text you need exact, composite the text in after the model pass. The model will not preserve it faithfully. Files HF: https://huggingface.co/AI-KSK/h3-hero-shot-qwen21-composite ModelScope: https://modelscope.cn/models/Sunjian520/h3-hero-shot-qwen21-composite Video walkthrough (Chinese): https://youtu.be/K6HI-iuMXeg Bilibili: https://www.bilibili.com/video/BV1AsHy6nEPR/ Notes Two ComfyUI workflow exports; Qwen Image 2.1 and H3 weights must exist locally. Tutorial material, not a product. Independent AI-KSK release; not affiliated with the model authors.

Powered by Readybot.io

DEV Community

SaaS Phased Rollout Checklist

Deploying updates to a multi-tenant cloud application often causes unexpected production errors, silent regressions, or user friction when pushed to all users simultaneously. Quick solution: Use a staging slot configuration and feature flags to isolate new code paths before promoting traffic, as detailed in the Azure App Service deployment staging slots documentation. az webapp deployment slot swap --name myApp --resource-group myResourceGroup --slot staging
Prerequisites: Ensure your application uses environment-agnostic connection strings and health check endpoints before executing slot swaps. Product teams frequently struggle to balance the speed of continuous delivery with the safety of cautious exposure. When an entire user base receives a breaking schema change or an unoptimized database query at once, telemetry spikes and customer support queues overflow. A structured rollout prevents widespread failures by confining anomalies to an initial, smaller cohort of users. Understanding how to execute these rollouts systematically helps engineering and product groups coordinate releases without relying on guesswork or risking complete system downtime. Understanding Staged Exposure and Pilot Selection Staged exposure involves routing a fraction of production traffic to an isolated environment or applying feature toggles to specific tenant groups. Rather than relying on gut feeling, teams must establish clear criteria for pilot selection. Internal teams, opt-in beta testers, and low-traffic enterprise accounts often serve as the initial validation cohort. These groups provide a controlled perimeter where unexpected exceptions or performance bottlenecks surface before hitting enterprise-tier customers. Selecting the right pilot group requires evaluating user behavior variability and traffic density. If your initial cohort consists solely of internal developers, your telemetry will not reflect real-world usage patterns because internal teams understand expected workflows and avoid edge cases. Instead, select a representative sample of external users who span different geographic regions, subscription tiers, and client operating systems. This practice helps teams Post-Deploy Sanity Checks: Verify Production Without Re-Running Your Test Suite to ensure alignment between technical execution and product requirements before code reaches production. When scaling up pilot cohorts, establishing telemetry baselines is mandatory. Product managers should define exact metrics such as API response latency, database connection pool saturation, and HTTP 5xx error frequency. If any of these metrics deviate by more than a predefined percentage during the pilot phase, the deployment pipeline halts automatically. This prevents minor front-end anomalies from cascading into severe backend service degradation. Configuring Feature Flags and Health Signals Feature flags decouple code deployment from feature release. By wrapping new UI components or backend logic in conditional checks, engineers can deploy code safely ahead of time and toggle features on dynamically. However, managing dozens of active flags introduces technical debt if cleanup strategies are neglected. Teams must assign an expiration date to every feature flag, ensuring stale conditional code blocks are systematically purged from the repository after general availability. Monitoring health signals during this phase is equally important. Integrating application telemetry with dashboard platforms, such as those described in the Azure Monitor insights overview guide, allows engineers to observe performance regressions, error rates, and latency shifts in real time. If error rates exceed baseline thresholds, automated triggers should disable the flag or revert the traffic split. Furthermore, observability tools must track background worker queues and asynchronous job success rates, as silent failures in background processing often go unnoticed by standard HTTP health probes. Comparing Rol...

Powered by Readybot.io

DEV Community

The Quiet Suspect

The traffic had been recorded as coming from her home. Cybercrime: Malice in Everyday Life — Part 7 You don't have to be someone special to be targeted. Everyday life has unseen points of entry. Drawing on publicly available information, we trace how these threats unfold quietly and how their consequences eventually surface in everyday life. The police came to her door that morning A little after 8 a.m. Gina, a freelancer, was just starting up her computer when the doorbell rang. She opened the door. Two police officers were standing outside. "We'd like to ask you a few questions." Gina was taken aback by the unexpected visit. The officers explained that the IP address assigned to her home internet connection had appeared in traffic logs related to an unauthorized-access incident involving a financial institution. "Who was using this connection at that time?" Gina had no idea what they were talking about. She had never attempted to break into a financial institution. She used online banking only to check her own account. "Could there have been some mistake?" She said this, but the officers told her they were following up on the basis of the records they had obtained. It was the first time Gina had learned that records existed showing criminally related traffic coming from her home. The computer she used every day Gina worked from home. She had bought her Windows PC for work a few years earlier. Email, documents, video calls, online banking—nothing out of the ordinary. A few months before, she had installed a free VPN app so she could communicate securely when working away from home. She had found the service online. It said she could connect to servers in other countries. She did not feel she needed to pay for a subscription. Since it was free, she thought she would give it a try. Nothing seemed wrong after she installed it. Her computer had not become slower. No unfamiliar files had appeared. There were days when she did not use the app, but she had no particular reason to uninstall it. Gina had installed free software many times before. She liked trying useful tools she came across, and she had antivirus software installed as well. She did not consider herself careless about security. The connection came from here To help answer the police's questions, Gina arranged to have the computer and network environment she had been using at the time examined. During the investigation, suspicious activity was found in an app she had installed. Her PC had been communicating with external systems even when she was not using it. And this was not ordinary app updating or routine background traffic. A malicious program had entered her computer without her knowledge. The program was using Gina's PC to relay communications for someone else. Someone somewhere else was connecting to the internet through her computer. To an external service, the traffic appeared to originate from the IP address assigned to Gina's home. In other words, the person actually operating the connection was somewhere else, but the records showed Gina's home as the source. The actual criminal
|
| Traffic routed remotely
v
[Gina's PC]
Malicious program
|
| Through Gina's internet connection
v
[Internet]
|
| Unauthorized access
v
[Financial institution]
|
v
Source IP address
recorded in logs
|
v
Gina's home
Gina had not been doing anything. Even so, her PC had been used in someone else's crime. And the organization on the receiving end had a record showing that the access came through Gina's connection. An everyday connection turned into a relay without her knowledge This kind of traffic relaying is known as a residential proxy. Like an ordinary proxy, it is a way to route someone else's traffic. What distinguishes it is that...

Powered by Readybot.io

DEV Community

The Future of Micro-Frontends: How to Combine Module Federation with Server-Side Rendering (SSR)

Client-side Module Federation has a well-known weakness, the browser downloads a shell, then fetches remotes, then renders. Users stare at a blank page, and crawlers may see very little. For content-heavy or SEO-sensitive products, that's a deal-breaker, and it's why teams keep asking the same question, can we get independently deployed micro-frontends and server-rendered HTML? The answer is yes, with caveats. Module Federation supports server-side rendering, and the same model that works in the browser transfers to Node, a host fetches code from remotes at runtime and renders it on the server. But SSR raises the stakes. You now have two runtimes to keep consistent, a network dependency inside your render path, and a security boundary you didn't have before. This guide explains how the pieces fit, shows a working configuration pattern, and is candid about where the ecosystem is solid and where it isn't. How Module Federation Works with SSR In client-only federation, a remote publishes a remoteEntry.js, and the browser loads it on demand. With SSR, each application builds twice, a browser bundle and a server bundle, each with its own federation entry. Request ──► Host server (Node)
│ 1. fetch remote's SERVER entry (cached)
│ 2. execute remote code, render to HTML stream
▼
HTML response ──► Browser
│ 3. load remote's CLIENT entry
▼
Hydration
Conceptually, the remotes act as static asset servers, the host's server pulls their server-side code and executes it in the same Node process that renders the page. That's what makes independent deployment possible, ship a new remote and the host picks it up without a rebuild, and it's also the source of most SSR-specific risk. Step 1 - Build the Remote Twice The remote exposes a component and produces a server entry alongside the client one. A server federation config typically targets a Node environment and uses the @module-federation/node runtime plugin: npm install @module-federation/enhanced @module-federation/node
// remote/webpack.server.js
const { ModuleFederationPlugin } = require('@module-federation/enhanced/webpack');

module.exports = {
target: 'async-node',
output: { path: __dirname + '/dist/server', libraryTarget: 'commonjs-module' },
plugins: [
new ModuleFederationPlugin({
name: 'productApp',
filename: 'remoteEntry.js',
library: { type: 'commonjs-module' },
exposes: { './ProductList': './src/ProductList' },
runtimePlugins: [require.resolve('@module-federation/node/runtimePlugin')],
shared: { react: { singleton: true }, 'react-dom': { singleton: true } },
}),
],
};
The client config mirrors our earlier micro-frontend setup (target: 'web', output to dist/client). Serve both directories from the remote's static host so each has its own entry URL, for example /server/remoteEntry.js and /client/remoteEntry.js. Config details vary by version, so treat this as a pattern and confirm option names in the current docs. Step 2 - Load Remotes at Runtime on the Host On the host's server, use the federation runtime to register and load remotes dynamically rather than hardcoding them at build time: // host/server/federation.ts
import { init, loadRemote } from '@module-federation/enhanced/runtime';

init({
name: 'host',
remotes: [
{ name: 'productApp', entry: ${process.env.PRODUCT_APP_URL}/server/remoteEntry.js },
],
});

export async function loadProductList() {
const mod = await loadRemote<{ default: React.ComponentType }>('productApp/ProductList');
return mod?.default ?? null;
}
Then render with a timeout and a fallback so a slow remote can't hang your page: // host/server/render.tsx
import { renderToPipeableStream } from 'react-dom/server';

export async function renderPage(res, props) {
const ProductList = await withTimeout(loadProductList(), 800).catch(() => null...

Powered by Readybot.io

DEV Community

⁧إرسال العملاء المحتملين إلى Odoo دون أن يضيع أحد: صندوق صادر معاملاتي في ASP.NET Core⁩

⁧عميل محتمل يصل إلى الموقع ولا يصل إلى فريق المبيعات أسوأ من ألا يكون هناك موقع أصلًا. سيتوقف نظام إدارة العملاء أحيانًا، والمهم أن ينتظر العميل المحتمل بدل أن يختفي.⁩ ⁧كتابتان، وإحداهما ستفشل⁩ ⁧أن تحفظ العميل المحتمل ثم تتصل بـOdoo يبدو سليمًا حتى يفشل الاتصال بعد الحفظ: العميل في قاعدة بياناتك، ولا أثر له عند المبيعات. وأن تتصل بـOdoo أولًا يفشل بالعكس، حين ينكسر الحفظ بعد أن صار السجل في النظام. وإعادة المحاولة داخل الطلب لا تفعل إلا أن تُبطئ الصفحة ما دام النظام متوقفًا.⁩ ⁧الصندوق الصادر يُخرج الكتابة الثانية من الطلب. السجل نفسه ورسالة تصفه يُحفظان في المعاملة نفسها، فإما أن يوجدا معًا أو لا يوجد أي منهما. وتسليم الرسالة يصير مهمة منفصلة تأخذ ما يحتاجه النظام من وقت.⁩ ⁧حفظ واحد، ومعاملة SQL واحدة⁩ // The enquiry and its outbox row commit together, or not at all.
db.Inquiries.Add(inquiry);
db.OutboxMessages.Add(new OutboxMessage
{
Type = "InquiryCreated",
AggregateId = inquiry.Id,
PayloadJson = JsonSerializer.Serialize(InquiryPayload.From(inquiry)),
OccurredUtc = now,
Status = OutboxStatus.Pending,
NextAttemptUtc = now,
});
await db.SaveChangesAsync(ct);
⁧ماذا تحمل الرسالة⁩ ⁧اجعل السجل مملًّا وكاملًا. لا يجب أن يخمّن المُرسِل أبدًا ما هي الرسالة، ولمن هي، ولماذا فشلت آخر مرة.⁩ ⁧النوع. ما الذي حدث: استفسار جديد، أو مورد اعتُمد، أو بريد يجب إرساله.⁩ ⁧السجل والحمولة. معرّف السجل الذي تخصه، ولقطة JSON بما يحتاجه الطرف الآخر.⁩ ⁧الحالة. معلّقة، أو قيد المعالجة، أو مُعالَجة، أو ميتة. لا شيء بينها.⁩ ⁧المحاولات. كم محاولة حتى الآن، ومتى موعد التالية.⁩ ⁧عقد الإيجار. أي عامل يمسك الرسالة، وحتى متى.⁩ ⁧آخر خطأ. رمز وسبب قصير، لا الحمولة ولا تتبع أخطاء مليء ببيانات شخصية.⁩ ⁧استلم كل رسالة بعقد إيجار مؤقت⁩ ⁧مهمة متكررة في Hangfire تعمل كل 30 ثانية وتمر على الرسائل المستحقة، الأقدم أولًا، لمدة 20 ثانية أو 500 رسالة على الأكثر. وتستلم سجلًا واحدًا في كل مرة بتحديث مشروط: لا ينتقل إلى قيد المعالجة إلا سجل معلّق حان موعده، أو سجل قيد المعالجة انتهى عقده، مع عقد مدته خمس دقائق ومعرّف العامل.⁩ ⁧إن لم يلمس التحديث أي سجل فقد سبقه عامل آخر، فينتقل إلى غيره. ولا يمكن وضع علامة النجاح أو الفشل إلا ما دام العامل يمسك العقد، فلا يكتب عامل تأخر بعد انتهاء عقده فوق عمل من استلم بعده. ورسالة عامل تعطّل تعود وحدها حين ينتهي العقد.⁩ ⁧استلم، أو انتقل إلى غيرها⁩ var claimed = await db.OutboxMessages
.Where(m => m.Id == id &&
((m.Status == OutboxStatus.Pending && m.NextAttemptUtc <= now) ||
(m.Status == OutboxStatus.Processing && m.LeaseExpiresUtc < now)))
.ExecuteUpdateAsync(s => s
.SetProperty(m => m.Status, OutboxStatus.Processing)
.SetProperty(m => m.LeaseExpiresUtc, now.AddMinutes(5))
.SetProperty(m => m.LockedBy, workerId), ct);

if (claimed == 0) continue; // someone else has it
⁧اجعل الكتابة في النظام آمنة إذا تكررت⁩ ⁧قد تُسلَّم الرسالة ثم يتعطل العامل قبل أن يسجل ذلك. المحاولة التالية يجب ألا تنشئ عميلًا محتملًا ثانيًا. لذلك يُكتب معرّف GUID الخاص بالسجل في حقل مخصص على العميل في Odoo، وكل تسليم يبحث به أولًا: يحدّث إن وجده، وينشئ إن لم يجده. وجدول للتسليمات بمفتاح فريد لكل مزوّد وعملية وسجل يُبقي صفًّا واحدًا لكل إرسال منطقي.⁩ ⁧لكن البحث ثم الإنشاء ما زالا اتصالين. إن جرت رسالتان للسجل نفسه في الوقت نفسه، قد لا تجد أي منهما شيئًا فتنشئ كلتاهما. عالج رسائل السجل الواحد بالترتيب، أو ضع قيدًا فريدًا على ذلك الحقل في Odoo؛ الحقل وحده لا يجعل العملية ذرية.⁩ ⁧أعد محاولة ما يمكن أن يُشفى، وأمِت ما لا يُشفى⁩ ⁧كل فشل يأتي من عميل Odoo يُصنَّف مرة واحدة في مكان حدوثه، فلا يحتاج المُرسِل إلا إلى قراءة الجواب.⁩ ⁧أضف تفاوتًا عشوائيًا إلى فترات الانتظار، حتى لا تعيد دفعة من الإخفاقات المحاولة في الدقيقة نفسها.⁩ ⁧عامِل 408 و429 كأخطاء عابرة، واحترم Retry-After. من السهل تصنيفهما دائمين بالخطأ.⁩ ⁧اجعل إعادة المحاولة اليدوية تصفّر عدد المحاولات، وإلا نالت الرسالة الميتة محاولة واحدة ثم ماتت من جديد.⁩ ⁧أنواع الفشل، وما يفعله المُرسِل⁩ ⁧ما يحدث⁩ ⁧النوع⁩ ⁧الفشل⁩ ⁧إعادة بعد دقيقة، ثم 5 و15 و60 و360⁩ ⁧عابر⁩ ⁧انتهاء المهلة، خطأ شبكة، 5xx⁩ ⁧رسالة ميتة فورًا، ويظهر على العميل أن مزامنته فشلت⁩ ⁧دائم⁩ ⁧401 و403 وأي 4xx آخر⁩ ⁧رسالة ميتة فورًا⁩ ⁧دائم⁩ ⁧حمولة لا يمكن تحويلها⁩ ⁧رسالة ميتة، وتنبيه للم...

Powered by Readybot.io

DEV Community

Game Analytics: The Events Every Mobile Game Should Track

The short answer Track a small, planned set of events in six groups: sessions, the first-launch funnel, progression, economy, monetization and technical health. Write them in a tracking plan before coding, name them consistently and attach parameters. With about twenty well-chosen events you can calculate retention, find where players quit, balance the economy and see why revenue rises or falls. Start from questions Events exist to answer questions. Write the questions first. Where do new players drop out in the first ten minutes? Which level is too hard? Are players running out of currency or sitting on piles of it? Which ad placement is used most? Do players who use a feature stay longer? Is the game stable on low-end phones? If an event answers none of your questions, do not add it. The core event list Group Event Key parameters Session session_start, session_end Session number, duration Onboarding tutorial_step Step name or number, time since install Onboarding first_level_complete Time since install Progression level_start Level, attempt number, character or loadout Progression level_complete Level, duration, score, stars, boosters used Progression level_fail Level, reason, progress percentage, attempt number Economy currency_earned Currency, amount, source Economy currency_spent Currency, amount, item, sink Monetization shop_opened Entry point Monetization purchase_started, purchase_completed, purchase_failed Product, price, currency, failure reason Ads ad_opportunity, ad_shown, ad_completed, ad_reward_granted Placement, type, network Engagement feature_used Feature name Engagement daily_reward_claimed Day in streak Engagement notification_opened Notification type Technical loading_time Scene, seconds Technical error Type, context Most analytics tools record installs, device model, country and app version automatically. The first-launch funnel The steepest loss of players happens in the first session, so instrument it most carefully. Fire an event at each step: app opened, loading finished, each tutorial step, first action, first win, return to menu, second level started. View these as a funnel. A large drop between two steps points to a specific problem: a long load, a confusing instruction, a forced sign-up. Fixing the worst step is often the cheapest retention gain available. See mobile game KPIs for what good retention looks like. Progression events Level start, complete and fail are the backbone for any level-based game. Completion rate per level shows difficulty spikes. Attempts per level shows frustration. Fail reason and progress show whether players lose at the start or one move from the end, which call for different fixes. Time per level helps content planning. Games without levels use equivalents: match start and end, quest accepted and completed, zone entered. See level design principles. Economy events Record every time a currency enters or leaves a player's balance, with the source or sink. This reveals: Inflation, when players earn far more than they spend. Starvation, when progress stalls for lack of currency. Which sinks players value. The effect of a balance change, by comparing before and after. This is essential for free-to-play games. See game economy design. Monetization events For purchases, track the whole path from shop opened to purchase completed, including failures with reasons. For ads, track the opportunity, the impression and the completed reward by placement. That tells you which placements players choose and where fill is poor. Background is in in-app purchase implementation, rewarded ads design and ad mediation. Naming rules One style everywhere. Lowercase with underscores is the common convention. Object then action. level_start, level_complete, purchase_completed. Parameters, not names. One level_complete event with a level parameter, not level_1_complete, level_2_complete. Stable names. Renaming an event breaks historical comparisons. Consistent units. Seconds, not a mix of second...

Powered by Readybot.io

DEV Community

The Sample Passed. What Did We Actually Prove?

Why a clean control test can still leave a decision maker exposed By Manfredi Marrocco The report says every sampled access removal was completed on time. The dashboard turns green. A manager asks whether the company can now rely on its leaver process. There is a missing question: did the sample come from a complete list of leavers? If the test began with tickets already created in the identity system, it may have excluded precisely the cases where nobody created a ticket. Ten well-processed tickets can demonstrate that those ten tickets were well processed. They cannot, by themselves, establish that all departures entered the process, or that the same process worked in every subsidiary. This distinction has practical consequences. A control assessment does not merely collect proof that an activity happened; it establishes how far that proof can support a decision. The boundary depends on the control objective, the population, the test and the period examined. A pass without those boundaries can be more misleading than an explicit limitation. Return of the Obra Dinn as a decision lens In Return of the Obra Dinn, the player investigates a ship and reconstructs events through observation and deduction. The official description establishes that investigative premise. The connection to control assessment is the discipline of asking what an observation can support. It is not a claim that a fictional investigation follows an audit standard. The useful connection is the boundary of a deduction. A ticket constrains the account of a recorded departure; it cannot establish the complete departure population. The game offers a designed mystery. An organisation must also account for evidence that is unavailable and conclusions that remain unresolved. Start with the claim, not the screenshot Consider a fictional organisation, Northstar Distribution. Its policy says that relevant access for departing employees must be removed within a defined period after departure. The assessment team receives ten closed tickets, each with a timestamp and an apparent approval. All ten meet the organisation's internal deadline. The example is hypothetical: neither the deadline nor the sample size represents a universal requirement. What has been shown? For the ten selected records, the ticket system contains information consistent with timely completion. That is a useful observation. It is not yet the same as showing that every departure was captured, that all relevant accounts were disabled, or that an account could not be reactivated later. The claim can be broken into questions: Coverage: Were all in-scope departures identified, including contractors where the control applies? Execution: Were the required actions completed by the applicable deadline? Completeness of action: Did the actions cover the relevant systems and privileged accounts? Persistence: Did access remain removed, or did a later event restore it? Period and scope: Which entities, services and dates were actually examined? Each question calls for different evidence. A ticket timestamp may speak to execution. It is weaker evidence of coverage when the ticket list is the only source of the population. A screenshot of a disabled account may demonstrate its state at a particular time, but not necessarily when it changed or whether other accounts existed. NIST's definition of a security control assessment distinguishes correct implementation, operation as intended and the desired outcome against security requirements. Those are related but separate questions. NIST SP 800-53A provides tailorable assessment procedures and planning guidance; it is a US framework, and its use here is methodological guidance, not a claim that every organisation is legally bound by it. The population is part of the test A sample can only be interpreted against the population from which it was selected. If Northstar tests only identity-system tickets, its population is “tickets recorded in that system,” not automat...

Powered by Readybot.io

** Latest from PC Gamer **

YouTuber and comedian Ashens has 1,000 hours in Baldur's Gate 3 and reveals the worst retro game he's ever played: 'By the time you've hacked it to work, it's just no fun whatsoever'

The filmmaker and author of Terrible Old Games You've Probably Never Heard Of gives us a tour of his Steam library.

Powered by Readybot.io

DEV Community

豆包 Seed 2.1 API 接入 Tokuse：Pro / Lite / Turbo 价格、效果与选型指南

Tokuse 已经接入 ByteDance 豆包 Seed 2.1 系列的三个模型，并且统一提供 OpenAI 兼容接口。对正在控制 AI 成本的团队来说，这不是多了一个模型选项，而是多了一组价格梯度：同样一套代码，可以在 Pro、Lite、Turbo 之间按任务切换，把能力档位和成本档位分开管理。 本文基于 2026 年 11 月 16 日 Tokuse 线上模型目录，对比 doubao-seed-2-1-pro-260915、doubao-seed-2-1-lite-260915、doubao-seed-2-1-turbo-260628 的价格、适用场景和接入方式。所有价格以 Tokuse 定价页 的实时数据为准，采购前请重新核对。 一句话结论 模型 ID 输入 / 百万 Token 输出 / 百万 Token 协议 适合场景 doubao-seed-2-1-pro-260915 $0.8220 $4.1100 OpenAI、Anthropic 复杂推理、长文分析、质量优先的 Agent 步骤 doubao-seed-2-1-lite-260915 $0.1096 $0.3699 OpenAI、Anthropic 日常对话、摘要、抽取、分类、高并发自动化 doubao-seed-2-1-turbo-260628 $0.0876 $2.1900 OpenAI、Anthropic 超长输入、极短输出，输出 Token 必须严格受控 两个关键差异： Lite 是平衡型工作负载的成本底线。 在当前 Tokuse 价格下，它的输入和输出单价都比 DeepSeek Flash 低约 60% 和 66%。 Turbo 不是"更便宜的 Lite"。 它的输入单价最低，但输出单价约为 Lite 的 5.9 倍。只有输入很长、输出很短的任务才适合 Turbo。 Pro 是能力档，不是默认档。它适合 Lite 达不到质量线的那部分任务，而不是所有请求都走 Pro。 三个模型分别适合什么 豆包 Seed 2.1 的三个档位是按工作负载形态划分的，不是按一个跑分排序。 豆包 Seed 2.1 Pro 是这一系列的能力档。多步规划、工具调用、长文档分析、对指令遵循要求高的回答，应该优先在 Pro 上验证。它的输出价格是三档中最高的，所以适合"答错比 Token 更贵"的任务。 豆包 Seed 2.1 Lite 是平衡档，也是最值得作为默认选项的模型。客服、摘要、结构化抽取、打标签、分类、常规 Agent 步骤都可以先跑 Lite。$0.1096 的输入价和 $0.3699 的输出价，让高请求量场景的成本更可控。 豆包 Seed 2.1 Turbo 面向输入重、输出轻的任务。例如读取很长的上下文，最后只返回一个标签、一个 JSON、一条路由判断。它的输入价 $0.0876 是三档最低，但一旦生成长答案，$2.1900 的输出价会迅速放大账单。 实际策略可以很简单：默认 Lite，用真实提示词做评测；达不到质量线的意图升级到 Pro；只有输出长度确实受控的任务才用 Turbo。 一个真实工作负载的成本 只看单价容易误判。输出占比一高，账单结构就会变。 以 1 亿输入 Token + 2000 万输出 Token 为例，把豆包 Seed 2.1 和 Tokuse 上的两个 DeepSeek 模型放在一起比较： 模型 输入成本 输出成本 合计 豆包 Seed 2.1 Lite $10.96 $7.40 $18.36 DeepSeek Flash $27.40 $21.92 $49.32 豆包 Seed 2.1 Turbo $8.76 $43.80 $52.56 豆包 Seed 2.1 Pro $82.20 $82.20 $164.40 DeepSeek V4 Pro $123.20 $73.96 $197.16 在这个输入输出比例下，Lite 比 DeepSeek Flash 便宜约 63%。Turbo 因为输出单价高，反而略贵于 DeepSeek Flash。Pro 的成本接近 DeepSeek V4 Pro，符合能力档的定位。 换一个工作负载，排序会变： 工作负载 豆包 Lite 豆包 Turbo DeepSeek Flash 8000 万输入 + 400 万输出 $10.25 $15.77 $26.30 1000 万输入 + 5000 万输出 $19.59 $110.38 $57.54 长报告、代码生成、多轮对话这类输出偏重的工作，Lite 仍然是这组里最便宜的。Turbo 只有在输出占输入比例极低时才有优势。 缓存价格不能忽略 DeepSeek 提供缓存命中价格，Tokuse 的模型目录也暴露了对应的缓存倍率。按当前 deepseek-flash 价格，缓存命中输入约为每百万 Token $0.006，远低于未命中的 $0.274。 豆包 Seed 2.1 在 Tokuse 目录中的报价不包含缓存折扣假设。如果你的应用会反复复用同一段长系统提示词或 Agent 上下文，先测算缓存命中比例，再判断 Lite 是否一定更便宜。对于输出很小的任务，高缓存命中率的 DeepSeek Flash 有可能在总成本上反超 Lite；对于输出很重的工作，Lite 的低输出价仍然是决定因素。 这也是为什么应该用 成本计算器 和 Tokuse 的用量日志来验证，而不是只看一个首页单价。 用 OpenAI SDK 调用豆包 Seed 2.1 三个模型都接受 https://tokuse.com/v1 的 OpenAI 兼容 Chat Completions 请求。保留现有 SDK，只改 base URL 和模型 ID。 import os
from openai import OpenAI

client = OpenAI(
api_key=os.environ["TOKUSE_API_KEY"],
base_url="https://tokuse.com/v1",
)

response = client.chat.completions.create(
model="doubao-seed-2-1-lite-260915",
messages=[
{"role": "system", "content": "把客户意图抽取为 JSON。"},
{"role": "user", "content": "我被重复扣费了，需要退款。"},
],
)

print(response.choices[0].message.content)
Node.js 的写法相同： import OpenAI from "openai";

const client = new OpenAI({
apiKey: process.env.TOKUSE_API_KEY,
baseURL: "https://tokuse.com/v1",
});

const response = await client.chat.completions.create({
model: "doubao-seed-2-1-pro-260915",
messages: [{ role: "user", content: "总结这份合同。" }],
});
也可以直接发 HTTP 请求： curl https://tokuse.com/v1/chat/completions \
- H "Authorization: Bearer $TOKUSE_API_KEY" \
- H "Content-Type: application/json" \
- d '{
"model": "doubao-seed-2-1-turbo-260628",
"messages": [{"role": "user", "content": "分类：退款请求"}],
"temperature": 0
}'
也可以使用 Anthropic Messages 协议 豆包 Seed 2.1 在 Tokuse 上同时支持 Anthropic Messages 格式。把 base URL 设为 https://tokuse.com，路径由 SDK 处理： import os
import anthropic

client = anthropic.Anthropic(
api_key=os.environ["TOKUSE_API_KEY"],
base_url="https://tokuse.com",
)

message = client.messages.create(
model="doubao-seed-2-1-pro-260915",
max_tokens=1024,
messages=[{"role": "user", "content": "规划一个三步迁移方案。"}],
)

print(message.content[0].text)
如果现有系统已经用 Anthropic 兼容客户端跑 Claude，这条路可以让你不引入第二个 SDK 就完成豆包测试。完整的协议说明见 Anthropic Messages 指南。 流式、超时和常见错误 流式调用和其他 OpenAI 兼容模型一致： stream = client.chat.completions.create(
mo...

Powered by Readybot.io

DEV Community

useEffect vs useLayoutEffect: Why the Tooltip Flashes, Then Jumps

Picture a tooltip that should sit above a button. For one frame it shows up at the top of the box, then it jumps into place. The measurement was right. It ran too late. useEffect let the browser paint the first, wrong position. The mental model: before the curtain, or after React updates the DOM, then the browser paints what the user sees. There is a gap between those two, like the moment before a curtain opens. useLayoutEffect runs in that gap, while the curtain is closed. useEffect runs after the curtain opens, once the user can already see the frame. Both take the same arguments: a setup function, a dependency list, and an optional cleanup. The only difference is when the setup runs. One update, from commit to paint 1. React writes the DOM — The new elements are in the document
2. useLayoutEffect — Measure and correct, still invisible
3. Browser paints — This is the frame the user sees
4. useEffect — Fetch, subscribe, log
The user only sees the frame after useLayoutEffect has finished. How it works useEffect is the one for work that talks to the outside world: a fetch, a subscription, a timer, a log line. The browser paints first, so the effect doesn't hold the frame up. The user sees the new UI, then the effect runs. useLayoutEffect is for the case where that first paint would be a lie. You need a number the browser only knows after layout, such as a height from getBoundingClientRect, and you need to change what's on screen with it. useEffect(() => {
const { height } = tipRef.current.getBoundingClientRect();
setTop(buttonBottom - height); // one frame at top: 0, then it jumps
}, [buttonBottom]);
Swap in useLayoutEffect and that setTop is flushed before the browser paints. React may render the tooltip twice, first at top: 0 and then at the measured spot. The user only sees the second render. That correction is also the cost. The code inside useLayoutEffect, and any state update it schedules, blocks the paint. A slow one delays the frame. The React docs say to prefer useEffect unless that blocking is the point. The dependency list works the same on both. It still decides when the effect re-runs, and a stale value is still stale. Timing doesn't change that. The rules are in useEffect dependencies. In practice Start with useEffect. Move to useLayoutEffect only after you've seen a flash. The flash shows up when you read layout and then write the screen: A tooltip or menu that must flip above or below, depending on the space left. A textarea whose height follows its content. Scrolling or focusing an element before the user sees it in the wrong place. Leave fetching, subscriptions, and logging on useEffect. They don't change the frame that's about to paint. Running them in useLayoutEffect makes that paint wait for work the user didn't need to wait for. Honest stakes: most components never measure the DOM. You'll want useLayoutEffect a handful of times, usually on something floating. Reaching for it to be safe makes the first paint slower. Wait until something flickers. Say it in an interview "useEffect and useLayoutEffect take the same arguments. useLayoutEffect runs after React commits DOM changes and before the browser paints, so you can measure layout and correct it without a visible flash. useEffect runs after the paint, so it doesn't block the frame. State updates inside useLayoutEffect are flushed before that paint. Default to useEffect, and switch only when the user would otherwise see one wrong frame." Cheat sheet useEffect useLayoutEffect When it runs After the browser paints After the DOM update, before the paint Blocks the paint? No Yes Use it for Fetch, subscribe, log Measure layout, then fix what the user would see A state update inside Shows up on a later frame Flushed before the paint The default This one Only after you've seen a flash TL;DR useLayoutEffect runs before the paint. useEffect runs after it. The layout version can measure the DOM and correct it before anyone sees the...

Powered by Readybot.io

DEV Community

Spectral Clustering: Why the Eigenvectors of a Graph Laplacian Reveal Clusters

K-means is the first clustering method most people learn, and it is also the first one to fail in an instructive way. Give it two interleaving crescents, two concentric rings, or a long thin chain next to a dense ball, and it will cut straight through the structure you can see with your eyes. The failure is not a tuning problem. K-means assumes clusters are round blobs around a centre, and it measures closeness in raw Euclidean distance. When the shape of a cluster matters more than its centre, that assumption is wrong. Spectral clustering takes a different route. Instead of clustering points directly, it first turns the data into a graph, then asks a linear algebra question about that graph: which smooth, low-energy functions on the graph separate one region from another? The answer is given by the smallest eigenvectors of the graph Laplacian. Cluster in that eigenvector space, and crescents, rings, and chains suddenly become easy. This article explains what the Laplacian is, why its eigenvectors encode cuts, how the full algorithm works, and where it breaks down. From points to a graph Start with data points x1,…,xn . Spectral clustering does not work on the points themselves. It works on a weighted graph in which each point is a node and each edge weight wij measures how similar points i and j are. Similar points get a heavy edge, dissimilar points get a light edge or no edge at all. The clustering problem then becomes a graph partitioning problem: cut the graph into pieces so that few heavy edges are cut and each piece is internally well connected. The graph construction is the first real decision, and it matters more than most textbooks admit. Three common choices are: Epsilon neighbourhood graph: connect points closer than some radius ϵ . k-nearest-neighbour graph: connect each point to its k nearest neighbours, usually symmetrised by keeping an edge if either endpoint lists the other. Fully connected graph with a Gaussian kernel: connect everything, with weight decaying with distance. The Gaussian kernel is the usual default for a fully connected graph: wij=exp(−2σ2∣xi−xj∣2) Here σ is a scale parameter. Small σ makes the graph local: only genuinely near neighbours matter, and distant structure is ignored. Large σ makes the graph dense and blurs local detail. There is no universally correct σ , and a bad one can destroy the result before any eigenvectors are computed. In practice, a k-nearest-neighbour graph is often more robust than a fully connected Gaussian graph, because it adapts to varying density: a point in a sparse region still gets neighbours, and a point in a dense region is not swamped by weak long-range edges. Collect the weights into a similarity matrix W , with entries wij and zeros on the diagonal. Define the degree of node i as the total weight of its edges: di=j=1∑nwij Put the degrees on the diagonal of a matrix D . The unnormalised graph Laplacian is then: L=D−W That simple definition carries a surprising amount of structure. What the Laplacian measures Take any function f on the nodes, a vector with one value fi per point. The quadratic form fTLf has a clean expansion: fTLf=21i=1∑nj=1∑nwij(fi−fj)2 Read that carefully, because it is the whole intuition in one line. The quadratic form is a weighted sum of squared differences across edges. If f assigns similar values to strongly connected points, the sum is small. If f jumps across a heavy edge, the sum is large. So a function with small fTLf is smooth on the graph: it varies slowly inside well-connected regions and only changes where the graph is weakly connected. That is exactly what a cluster indicator should do. An ideal cluster indicator is constant inside each cluster and jumps only between clusters. If clusters correspond to weakly connected regions, the jump crosses only light edges, so the quadratic form stays small. Spectral clustering is, in this sense, a search for smooth functions on the graph. The Laplacian is symmetric and positive sem...

Powered by Readybot.io

DEV Community

Top Million Websites Saw Visits Fall 12.2% From Their 2022 Peak

Browser-based visits to the world’s top million websites were 12.2% below their 2022 peak by the third quarter of 2026, according to SparkToro’s analysis of Similarweb data. The finding matters because it describes a broad contraction in traffic flowing across the measurable open web, even while internet use continues to grow. For SEO teams, the result is less a verdict on any one channel than a reason to recalibrate. A decline in total available browser traffic can affect organic performance expectations, traffic forecasts and the way businesses evaluate search visibility. It also strengthens the case for measuring discovery beyond a single session or a single search result page. What SparkToro’s data found SparkToro’s open-web traffic analysis compares global browser visit data supplied by Similarweb over time. Its figures show that total visits to the top million websites had fallen 12.2% from their 2022 high by Q3 2026. The analysis also reported a 29.2% decline in visits per internet user. That per-user measure is important, but it should be read with care: SparkToro notes that revised internet-user estimates from DataReportal contributed to the change in the calculation. At the same time, the relative distribution of visits among the largest sites did not shift dramatically. The combined share going to the top 1 to 10 sites was roughly 33% in 2021, while sites ranked 11 to 100 accounted for about 36%. Those shares had moved only minimally by Q3 2026. Measure Observed finding What it indicates Visits to the top million websites 12.2% below the 2022 peak by Q3 2026 The overall browser-based open-web traffic pool was smaller than at its recent high. Visits per internet user Down 29.2% Per-user browsing declined in the analysis, though revised user estimates affect this metric. Share held by the largest sites Minimal movement from 2021 through Q3 2026 The largest websites remained disproportionately important rather than losing substantial share. Search Engine Journal’s coverage of the findings similarly emphasizes that the data concerns a global shift in browser traffic, not a measured change in paid advertising activity. A smaller traffic pool is not proof of one cause It is tempting to assign the decline entirely to AI-generated answers, zero-click searches or changes in Google Search. Those forces may be relevant to how people discover information, but this dataset does not isolate their impact. The released analysis is global, has no regional breakout and measures browser activity rather than app traffic. It also does not provide device-level detail in the supplied findings. As a result, it cannot show whether a particular country, industry, device type or search feature caused the observed change. That distinction matters. People can spend more time in apps, social platforms, messaging services and other closed environments that are not represented in browser-based open-web measurements. Changes in how internet users are counted also affect per-user comparisons. The data supports the conclusion that open-web browsing has weakened at a broad level. It does not establish a universal explanation for every website’s traffic decline. What the stable top-site share means The figures do not suggest a major redistribution of browser visits away from the web’s largest destinations. Instead, they indicate that the total volume of visits fell while the leading sites retained much of their collective share. For smaller businesses, publishers and ecommerce sites, this can make organic growth more difficult. Competing for demand remains necessary, but a rising position in search results may not produce the same number of visits it would have when the overall click pool was larger. A traffic-only view of SEO can therefore conceal real gains in rankings, visibility or qualified discovery. This does not mean smaller sites cannot win. It means they need a clearer view of where attention begins, where it goes next and which outcomes ...

Powered by Readybot.io

DEV Community

How I built a 1.8-second B2B Lead Scraper & 18-Signal Telemetry Auditor (Zero Headless Chrome)

Most website audit and B2B lead enrichment tools rely on heavy Headless Chrome queues that take 30–45 seconds per domain and cost hundreds of dollars a month in server overhead. I wanted to build an instant B2B prospecting and technical audit engine for web design, SEO, and PPC agencies that executes in under 2 seconds at the edge for £0 server cost. Here is the live platform running on Cloudflare Workers: 👉 https://leakradar.leakradar.workers.dev (If you want to test the locked Pro features—including the 250-domain Bulk CSV Scraper, Contact Vault, and White-Label Client Reports—click "Unlock Pro" in the top right and enter the 4-day developer key: VIP-4DAY) What It Does in ~1.8 Seconds When you enter any domain (or hit the JSON API), the Worker fires parallel asynchronous fetch() streams from the nearest Cloudflare PoP across /, /contact, /contact-us, and /about: 18-Signal DOM & HTTP Telemetry Inspection: Ad Pixels: Meta/Facebook Pixel (fbevents.js), TikTok Pixel, LinkedIn Insight Tag, Google Ads Conversion tags. Analytics & Enterprise Stack: GA4, Google Tag Manager, Segment, Tealium, Hotjar, Microsoft Clarity, OneTrust. Conversion Architecture: Live Chat widgets (Intercom, Crisp, Tidio, Drift, Zendesk), CRM/Booking embeds (HubSpot, Calendly, Klaviyo), Lead forms, and JSON-LD application/ld+json schema. Edge & Security: Measures live Time-To-First-Byte (TTFB ms), inspects strict-transport-security (HSTS), and detects CDN edge headers. Cloudflare data-cfemail Hex Decryption + Contact Scraping: Extracts verified corporate @domain emails, tel: phone lines, and social profiles across subpages. Includes a bitwise XOR hex decoder that automatically decrypts Cloudflare's data-cfemail email obfuscation on the fly:
javascript
function decCf(html) {
let out = [], r = /data-cfemail="([0-9a-fA-F]+)"/g, m;
while ((m = r.exec(html)) !== null) {
let s = m[1], k = parseInt(s.substr(0, 2), 16), e = "";
for (let i = 2; i < s.length; i += 2)
e += String.fromCharCode(parseInt(s.substr(i, 2), 16) ^ k);
if (e.includes("@")) out.push(e.toLowerCase());
}
return out;
}

Powered by Readybot.io

DEV Community

A Practical Guide to Choosing Between a VPS and Cloud Hosting

“Cloud” and “VPS” are sold as identities. In practice they are different ways to rent a computer and a network, with different bills, failure modes, and homework. The wrong choice is not usually “we picked VPS instead of AWS.” It is “we picked a topology nobody on the team can operate at 11pm.” Palmate Solutions’ cloud and DevOps work is Linux, Docker, reverse proxies, backups, and pipelines you can explain. We keep a capable VPS when it is sufficient. We do not migrate a straightforward business app into a maze of managed services without a reason. If you are evaluating how to run an independent instance, start with securing a Linux production server. This article assumes you have outgrown “one PHP folder on a panel” and are choosing how to run an application you actually own. What people mean by VPS A virtual private server is a virtual machine with a committed slice of CPU, RAM, and disk. You get SSH, a Linux userspace, and the obligation to patch it. Providers vary: some are a hypervisor in a well-run data centre; some are a control panel and a hope. You typically pay a flat monthly price. You operate the guest. Firewalls, users, TLS, database, backups, and deploys are yours unless you buy them as extras. That is the point: few surprises, few usage-based invoices, full control of what runs. Failure is usually the whole box. Disk fills, kernel lockup, provider host issue, or a botched upgrade. High availability means a second machine, replication, and a failover story — not a checkbox labelled “cloud.” A VPS is a strong default for a single business application, a modest traffic shape, and a team that can SSH safely. Many Indian SMEs run production this way for years when backups are tested and deploys are not “edit live over FTP.” What people mean by cloud hosting “Cloud” here means a platform of APIs: virtual machines plus load balancers, managed databases, object storage, secrets, autoscaling groups, and a bill that moves with usage. You can run one VM on a cloud provider and still be “on the cloud” in marketing. You are not using the platform until you use the platform. You operate a graph of services. That is powerful when you need independent scale, regional failover, or a managed Postgres with point-in-time recovery you do not want to run yourself. It is expensive and noisy when you only needed a reverse proxy and a container. Failure is partial until it is not. A managed database outage, an IAM misconfiguration, or a region event can look like “the site is up but login is dead.” Debugging requires knowing which product owns which hop. Cost is a product. Egress, load balancer hours, NAT gateways, and log ingestion surprise teams who compared a ₹x/month VPS to “the free tier.” Cloud is not automatically cheaper at small scale. It can be cheaper at large or spiky scale if you actually turn machines off and right-size. Compare the jobs, not the logos Job VPS-shaped answer Cloud-shaped answer Predictable monthly cost Easy Requires tagging, budgets, and discipline One app, one database, business-hours load Compose on one or two VMs Often overkill Need a second region tomorrow Painful, manual Designed for it, still not free Managed backups with restore drills You build the drill Vendor helps; you still drill Compliance questionnaires asking for vendor lists Short list Long list of subprocessors Team with one engineer Fewer moving parts More IAM and billing surface The interesting row is who can restore. A backup you have not restored is a rumour, on any provider. Cloud snapshots do not excuse you from a restore drill. VPS cron dumps to a bucket do not either. Uptime is a budget, not a feeling Vendors advertise 99.9% and 99.99% as if they were features you install. Those percentages are allowed downtime over a year, plus a pile of exclusions in the SLA. Convert them to minutes before you pay for redundancy you will not operate. The uptime calculator does that conversion. Pair it with understanding 99.9% vs 99.99% uptime...

Powered by Readybot.io

DEV Community

Access Control and Secrets Hygiene for Small Teams

Most small-company security incidents are not cinematic zero-day exploits orchestrated by foreign state actors. They are mundane, preventable operational oversights: a departed contractor who still holds an active SSH key to the production server, a live Stripe secret key pasted into a public Slack channel, or a shared [email protected] login with no multi-factor authentication. Palmate’s cloud and DevOps baseline is built around named identities, explicit secrets boundaries, and a verifiable joiner/leaver workflow. This is not an abstract enterprise IAM manual. For securing the host operating system, see how to secure a Linux production server. For structuring API authentication, review our guide on OAuth vs API keys for business integrations. If you suspect a credential has already leaked, consult what small companies should do after a security incident. The Identity Baseline: One Human, One Account Shared credentials are the enemy of security governance. The moment two engineers share an SSH login or a database management password: Audit trails become fictional: You cannot determine whether an anomalous record deletion was legitimate maintenance or an unauthorized breach. Offboarding becomes theatre: Revoking access for a departing employee forces you to change credentials across six shared systems and distribute the new passwords to everyone else—disrupting ongoing work. Core Identity Rules Individual named accounts: Every developer, operator, and contractor receives their own dedicated login across GitHub, AWS, cloud consoles, and database bastions. Hardware-enforced MFA: Mandatory multi-factor authentication on root identities (email provider, Git host, domain registrar, and cloud hosting provider). Use authenticator apps (TOTP) or hardware security keys (FIDO2)—never SMS verification. Role-based least privilege: Frontend contractors do not need read access to production databases. Backoffice operators do not need root access to VPS hosts. Access should be scoped strictly to current sprint deliverables. Secrets Are Not Configuration: The 4-Tier Secrets Taxonomy Treating API secrets as ordinary environment variables causes them to bleed into client bundles, log files, and bug trackers. Group your project values into four explicit tiers: Category Typical Examples Safe Storage & Exposure Leak Impact Tier 1: Public Config Site URLs, analytics IDs, feature flags. Committed in code, client-side bundles. None (intended for public web browsers). Tier 2: Sensitive Config Internal microservice URLs, non-sensitive port numbers. Environment files, server configs. Internal network mapping and recon. Tier 3: High-Risk Secrets Transactional email keys, SMS gateway tokens, OAuth secrets. Secret managers, runtime injection. Spam dispatch, SMS fraud, account takeover. Tier 4: Crown Jewels Production database root credentials, payment processor secret keys, master signing certificates. Encrypted vaults, restricted IAM, zero-developer access. Total database exfiltration, direct monetary theft. You can inspect non-production tokens using our browser-based JWT decoder when verifying claim signatures. Never paste production secrets or live authorization headers into third-party web utilities. Comparing Secret Storage Mechanisms Small teams often struggle with where to store secrets without slowing down daily delivery. Here is how modern approaches compare: 1. Plain .env Files on the Host The Good: Trivial to implement; supported natively by Docker Compose and language runtimes. The Risk: Files can be accidentally committed to Git, copied into backup archives, or read by compromised processes. Recommendation: Acceptable for local developer machines only. For production hosts, restrict permissions strictly: chmod 600 .env owned by root. 2. Encrypted Repositories (SOPS / git-crypt) The Good: Secrets are encrypted at rest using KMS or PGP keys; secret history is versioned alongside code. The Risk: Merge conflicts in encrypted blobs can be diff...

Powered by Readybot.io

DEV Community

Wild Shift Devlog #4: Don't lose your run

Fourth update on The Debugger 0x03: Wild Shift, my GitHub Game Off 2026 entry (theme: SHIFT). Devlog #1 covered the register and the shift, Devlog #2 the first two bosses, Devlog #3 the final boss and the ending. This post is a mirror of the fourth devlog on itch.io. You can also play the current build in the browser on the game page. The game is complete, and now it has to survive other people. Since the last devlog The Debugger 0x03: Wild Shift got its audio plumbing, a final sound pass, save and resume, a gamepad, a practice mode and a few quality-of-life switches. Less console.log("boss"), more return 0; with a nice exit code. Sound (Epic 7, part 1) Music plumbing. Each fight now has its own track and the game crossfades into it. In phase 3 a glitched variant of the track fades in step with the original, and while Breakpoint is active the music drops into a muffled loop, like someone put a pillow on the speakers. Dying and retrying is an instant cut, so you never wait for a song to catch up with your second attempt. Heads up: the tracks you hear right now are placeholders. They are generated loops that only prove the wiring works. I'm composing the real ones in BeepBox, and they'll drop in under the same file names with no code change. Please don't judge the music yet. Final SFX pass. 15 sound effects, all generated procedurally by a small script, so they are mine by construction. The two shift directions now have distinct clicks, every boss attack has its own tell cue (a sound before a hit, same rule as the visual tells), and the duck got a proper squeak. Don't lose your run (Epic 7, part 2) Save and resume. The game remembers the highest boss you reached. The title screen resumes from there, and [N] starts a new run. Mute is remembered too. If saving isn't available (private window, blocked storage), it silently falls back to a normal session. [B] debug build. An optional assist toggle for people who want to see the story: 8 HP instead of 5, a shorter Breakpoint cooldown, and slower boss tells. Damage numbers stay the same. It's saved, and it's named after the only thing a debugger really wants. Gamepad. Stick or d-pad to move, face and shoulder buttons for the actions and shifts, the right trigger for Breakpoint, Start to pause. Any button advances the title, intro and ending screens, so you can play start to finish without touching the keyboard. [F] fullscreen. On the title and the pause screen, by key, click or pad. Practice (Epic 7, part 3) The title screen now has [P] practice: a fight against the / test / dummy with a hit log and a frames N counter, available in every build. You can cycle through loadouts with L, so you can try a combo before you have earned it in the run. It writes nothing to your save and has no intro. Esc takes you back to the title. The title screen with the new options. ([N] new run shows up once you have a save.) Practice mode: the / test / target, the hit log and the frame counter. The pause screen now has mute, debug build and fullscreen rows. Measuring the run The last code story is a small playtest harness: the game prints [metrics] lines with the time to the first shift, the time and deaths per boss, and a total for a full run. No gameplay value changed, it only counts. I'll use it to tune what the numbers say is too hard or too easy, instead of what I feel at 1 a.m. I also added a build-size check to CI (the web build must stay under 32 MB), and the README, credits and this page's copy are done. The credits include mumble-speech, my own library, for the duck's voice. How it's made Same as before: I'm the director and the playtester, AI agents (Claude) write the code from specs I approve with the BMAD Method, and every story is a pull request with code review and automated tests. The test suite went from 112 to 121 test files. Everything is public in the GitHub repo. Next up What's left is the part only people can do: a full-run playtest, a browser check (Chrome, Firefox, Safari)...

Powered by Readybot.io

DEV Community

How to Tell If Your Mac App Has Been Cracked

Search your app name plus "crack", "cracked" or "free download" on Google, warez and torrent sites, and GitHub. Inspect a found copy with codesign -dv --verbose=4 and spctl -a -vv without launching it, then compare Team ID and cdhash to your release. https://fortifie.xyz/cracked runs the listings search faster, a search of public listings, not proof. This guide is for the developer who published the app, not for someone seeing a Gatekeeper warning. A cracked copy can appear on a warez site, a torrent index or GitHub without showing up in your analytics. How to check whether your Mac app has been cracked Start with a search, not a download. On Google, query your app name plus "crack", "cracked", "free download" or "dmg", and quote the name if it is generic. Repeat those queries on Mac warez sites and torrent indexes, then search GitHub for the app name, your bundle ID, or a distinctive Info.plist string. If a listing looks like your app, download the archive to an isolated folder. Do not launch the .app or drag it into /Applications. Mount a disk image if you have to, then point the tools at the bundle inside. codesign -dv --verbose=4 /path/to/Suspected.app
The codesign(1) man page describes --display (-d) as printing signature information; higher verbosity produces more fields. At --verbose=4 look for Identifier (usually your CFBundleIdentifier), TeamIdentifier (your Apple Developer Team ID), CDHash (the code directory hash for that architecture), and Authority (the certificate chain, typically Developer ID Application on a direct-distribution release). Compare TeamIdentifier and CDHash to the same output from the build you shipped. Apple's TN3126: Inside Code Signing: Hashes explains that the cdhash uniquely identifies the signed code. Matching values mean an unmodified copy of that signed build. A missing or ad hoc signature, or a different cdhash on a bundle that still looks like your app, can mean a patched or re-signed copy. For a universal app, codesign --display reports the native architecture of the Mac you are using, so check each slice with --arch arm64 and --arch x86_64. Display does not fully prove the signature is intact. The man page notes that --display is not a complete verification, and that --verify does not apply Gatekeeper or other OS policy. Also run: codesign --verify --deep --strict --verbose=2 /path/to/Suspected.app
spctl -a -vv /path/to/Suspected.app
spctl --assess (-a) asks the system policy subsystem whether the file would be allowed to run. The default type is execute, and verbose output typically includes accepted or rejected plus a source= line such as Notarized Developer ID or no usable signature. This is a policy check, not the same as opening the app. See Apple's TN3161: Inside Code Signing: Certificates for Team IDs, codesign --verify, and syspolicy_check. https://fortifie.xyz/cracked is a free search of public listings for your app, not proof. Don't run the cracked copy Treat an untrusted copy as malware until you have a reason not to. Warez installers often carry unrelated payloads. Your release records, plus the signature and file comparison below, can confirm the listing. codesign and spctl read the bundle and its signature; they are not the same as launching the app from Finder. For more isolation, inspect the copy in a virtual machine with no development keys or customer data, or just read the signature, Info.plist, resources and hashes. Confirm it's your build Match the version and the files Compare CFBundleShortVersionString, CFBundleVersion and CFBundleIdentifier in the copy's Info.plist to the release you shipped. Then compare file hashes for the main executable and, if you still have it, the shipping archive. An unmodified leak matches your release exactly: same cdhash, same Team ID, same file hashes. A patched crack will not, because the binary has changed, so also compare the bundle ID, version, icons and other resources. Record where and when you found it Keep the URL, the ...

Powered by Readybot.io

DEV Community

WARN Act and Layoffs in Pharmaceuticals and Biotech — What Drug and Biotech Workers Should Know

Drug and biotech companies rarely announce layoffs the way a factory closure does. The cuts arrive as pipeline pivots, post-acquisition integrations, and cash-runway restructurings — and when they are big enough, they show up as WARN notices. Five recent pharmaceutical and biotech filings in the Layoff Atlas registry cover 526 workers, from an 88-person research institute in Los Angeles to a 205-person generic-drug operation in New York. These are reported plans, not confirmed job losses — filings can be amended, delayed, or cancelled before the effective date. The recent filings The five filings span California, New York, New Jersey, and Maryland: Ellison Medical Institute, Los Angeles, California — 88 workers. The cancer research and biotechnology institute filed notice on November 4, 2026, for 88 permanent job cuts effective January 3, 2027, at its Exposition Boulevard campus — exactly 60 days' notice. Crinetics Pharmaceuticals, San Diego, California — 78 workers. The endocrine drug developer's cuts take effect January 4, 2027, following Vertex Pharmaceuticals' $10 billion acquisition, which closed September 1, 2026. The registry listing originally carried a mistyped 2026 effective date; trade reports confirm January 4, 2027. InvaGen Pharmaceuticals, Long Island, New York — 205 workers. Two sites: 160 workers in Central Islip and 45 in Hauppauge, both noticed August 28, 2026, and effective November 27, 2026 — 91 days' notice, both permanent layoffs. Teva Pharmaceuticals USA, Fairfield, New Jersey — 61 workers. Effective February 1, 2027, filed with the New Jersey Department of Labor and Workforce Development. The notice date is unavailable in the record, so the notice period cannot be checked from the filing alone. Pharmaceutics International, Hunt Valley, Maryland — 94 workers. Notice published October 30, 2026, effective December 29, 2026 — exactly 60 days. The company is listed as a Jabil Inc. company. A sixth filing shows the other end of the scale: DesigneRx Pharmaceuticals in Vacaville, California, filed a 7-worker notice effective November 15, 2026 — far below the federal thresholds, a reminder the registry records what employers file, not only qualifying mass layoffs. Why pharma layoffs look different Pharmaceutical layoffs follow the drug-development cycle more than the business cycle. Three patterns show up again and again: Post-acquisition integration. Crinetics is the clearest recent example: Vertex completed a $10 billion acquisition on September 1, 2026, and the 78 San Diego cuts followed as the two companies combined operations. Acquired companies' corporate functions — finance, IT, and administrative roles — are usually the first to go. Pipeline pivots. When a trial fails or a program is deprioritised, the team behind it is cut. Clinical-stage biotechs run on cash runway, and a restructuring that extends that runway by a few quarters is often the stated reason. Commercial restructuring. Larger drugmakers cut sales forces when a product line is reorganised. Industry trackers counted 90 biopharma workforce-reduction events in 2026, covering more than 27,446 roles — mostly global announcements, not US WARN filings. The notice period depends on the state The federal WARN Act generally requires employers with 100 or more full-time employees to give 60 days' notice of a qualifying mass layoff or plant closing. But the states where pharma concentrates add their own rules, and the recent filings show all three in action: California requires 60 days' notice from employers with 75 or more employees — a lower threshold than the federal law. Ellison's 60 days and Crinetics' roughly 62 days both clear it. New York requires 90 days' notice from employers with 50 or more employees. InvaGen's 91 days clears that bar by a single day. New Jersey requires 90 days' notice, and its law also mandates severance in covered layoffs. Teva's missing notice date means the timing cannot be verified from the public record — a gap wor...

Powered by Readybot.io