标签：#c

Its been almost 24 hours since reviews were released and I dont see the meta review still. Some people on reddit are saying they can see it. NeurIPS website says they are-releasing reviews on 23 but even 23 July is ending in 4 hours. Whats going on bruh, none of my coauthors is an AC or didnt complete his review so its not like its being held from us submitted by /u/Specialist-Manager67 [link] [留言]

Hi, I'm new with ACM conferences. I have 2 papers at workshops and the conference website says: "Each workshop paper needs to be associated with one workshop-only (non-student) or full (non-student) author registration at either ACM Member rate, or non-member rate. One workshop-only or full registration can cover only one accepted workshop paper." Does that mean that I have to register twice with "Workshop-only Author registration" paying 500USD per paper!? Second question, I really do not understand the APC fees listed here: ACM Multimedia 2026 Conference — Author Instructions .. does that means that in addition to the registrations I have to pay 350USD per paper? submitted by /u/rokk07 [link] [留言]

The data isn't the hard part. Cleaning it is. SEC EDGAR is public, free, and a mess. Every quarter, 13,000+ institutional investment managers file Form 13F, disclosing their U.S. equity holdings. In theory that's a beautiful dataset — every hedge fund, every pension fund, every bank, all in one place. In practice, the raw filings actively fight you: The same institution files under different names, sometimes even in the same quarter. In our own database right now: BlackRock, Inc. and BlackRock Inc. are two distinct CIK registrations for what most people would call "one" institution. Multiply that across 13,000+ filers and you get a long tail of near-duplicate names that break any naive GROUP BY institution_name . CUSIPs don't map cleanly to tickers. Foreign issuers frequently use CUSIP prefixes that don't resolve through the usual reference data — we ended up building a fallback resolution path (Yahoo Finance lookups plus manual validation rules) just to keep ticker coverage from silently degrading over time. Quarters arrive gradually, not all at once. The SEC gives managers up to 45 days after quarter-end to file. If you naively take "the latest quarter with any data" as your reporting period, you'll rank a barely-started quarter — where only a handful of small filers have reported so far — ahead of the real, complete prior quarter. We learned this the hard way: an unclamped "most recent quarter" query once let 115 newly-onboarded institutions' entire existing portfolios get counted as "new inflow" with nothing to offset them, because a first-time filer has no prior-quarter row to diff against. That's the kind of bug that doesn't throw an error — it just quietly produces a chart that looks plausible and is wrong. Amendments (13F-A) revise, replace, or partially restate earlier filings , and the XML schema itself has shifted over the years, so parsing "just the latest 13F" isn't a fixed target. None of this is exotic — it's the normal cost of working with real-world

How I Built an SSR Valorant Tracker with React, Supabase and Live Esports Data I recently built VALTRAIN , a player-focused Valorant platform that combines a Valorant Tracker, VCT match database and weapon skins explorer. The project started as a simple match history lookup page. It eventually became a much larger SSR application with player statistics, esports schedules, match detail pages, replay discovery, multilingual routes and searchable cosmetic data. The Main Product Areas VALTRAIN is divided into three primary areas. 1. Valorant Tracker The Valorant Tracker accepts a Riot ID and region. It can display: Current rank and RR Recent competitive and unrated matches KDA and combat score Headshot, body shot and leg shot data Competitive RR movement Lifetime performance statistics Individual match details and team compositions One challenge was handling incomplete or delayed data from an external player API. The interface needed useful loading, empty and error states instead of leaving users with an endless spinner. 2. VCT Match Database The VCT esports database stores upcoming and completed matches. Each public match can have: Tournament and stage information Team names and series scores Map-level results Player statistics Recent team form Official replay availability Related matches and internal links The project also includes an original VCT performance report generated from completed match records. 3. Valorant Weapon Skins The weapon skins database allows players to browse skins by collection, weapon type, rarity, price and chroma. The main performance challenge was preventing high-resolution media from slowing down the initial page load. Why I Moved the Site to SSR The original version relied heavily on client-side rendering. That worked for user interaction, but it created several problems: Public pages had limited initial HTML Search engines had to execute JavaScript Metadata was harder to control Dynamic routes occasionally returned weak fallback pages Firs

What happens when 5 parallel API calls hit for an expired JWT at the exact same millisecond. Imagine this: You’ve built a sleek, high-performance React dashboard. The UI is sharp, dark mode is gleaming, components are modularized, and React Query is executing parallel data fetches like a grand symphony. You brew a cup of coffee, open the app after lunch, hit refresh, and… BAM! You are immediately booted back to the Login screen. No warnings, no friendly error toasts—just a cold, ruthless redirect. You check your JWT expiration timer. The access token died 5 seconds ago, but your refresh token is valid for another 14 days. So why on earth did your app decide to kick you out like an uninvited party crasher? Welcome to the chaotic nightmare of Token Refresh Race Conditions in Axios Interceptors . In this article, we’ll walk through how parallel React queries can accidentally DDOS your own backend, why standard interceptor tutorials fail in production, how we built a promise-queue lock mechanism to solve it, and the subtle "gotcha" lurking in simple error detail checks that almost broke everything anyway. 1. The Problem: The Dashboard Stampede When a user logs into our app and opens the main dashboard, React Query triggers a stampede of concurrent API requests: GET /api/teams/users/ (Fetch team members) GET /api/teams/addresses/ (Fetch locations) GET /api/auth/profile/ (Fetch user profile) GET /api/auth/activity/recent/ (Fetch activity log) GET /api/notifications/ (Fetch unread alerts) Under normal circumstances, all five requests ride happily on the same valid Bearer <access_token> HTTP header. React App ---------------------------------------------> Django Backend GET /users/ [Bearer valid] ---> 200 OK GET /locations/ [Bearer valid] ---> 200 OK GET /profile/ [Bearer valid] ---> 200 OK The Ticking Time Bomb Fast forward 15 minutes. The short-lived access token expires. The user clicks on the "Analytics" tab. All 5 queries trigger at the exact same millisecond ( T = 0ms

In GoodBarber, you build an app without writing code: you assemble components, drag and drop, with a design system holding everything coherent underneath. Recently, a second way in appeared: you can get a custom section by describing it to an AI in plain language. Two ways of creating now live in the same back office — and the question comes immediately: is this the beginning of the end for drag & drop? No. And that "no" isn't a defensive reflex — it's an interface-architecture choice you can reason about. The ladder everyone knows The history of creation tools gets told the same way by everyone, and it's true: a ladder of abstraction. First, code — total control, total complexity. Then direct manipulation — drag & drop: you touch the rendering itself, the first great democratization. Then components — you stop aligning pixels and start assembling coherent elements, governed by a design system. And now the prompt — you describe, the machine produces. Each rung up, you move away from the mechanics and closer to the intent. None of that is a revelation. What gets told less often is the conclusion you reach when you actually operate a product sitting on that ladder: every time a new rung appeared, the prediction was the same — this one makes the others obsolete. It never came true. The prompt won't be the exception, and here's why. What drag & drop does better — and always will For anything that can be shown, direct manipulation is unbeatable. This button, two pixels lower; this image, at the top of the section; this menu, in this order: the gesture is the description — the sentence explaining it to an AI is longer than the action itself. And a visual interface does something besides taking orders: it shows you what's possible. A settings panel is a map of what the product can do; an empty prompt field is an invitation to guess. That's why the no-code core of the platform — component management, screens, navigation, design — stays drag & drop, deliberately. It isn't th

Back-of-the-envelope estimation for system design interviews Most people don't fail capacity math because the arithmetic is hard. They fail because they do it silently, produce a number they can't defend, and then never use it again for the rest of the interview. The math itself is trivial. The method is what's worth learning. Why interviewers ask Capacity estimation isn't a numeracy test. It's checking two things: Can you tell whether a design is physically possible before you commit to it? Do you know which constraint actually binds — storage, read throughput, write throughput, or bandwidth? A candidate who estimates 30,000 reads/sec and 200 writes/sec has learned something that changes the design. A candidate who computes petabytes of storage and then never mentions it again has just performed arithmetic. Round aggressively Precision is a trap. You're not producing a capacity plan; you're finding the order of magnitude. The single most useful substitution: 1 day = 86,400 seconds ≈ 10^5 seconds That's a 16% error and it makes every subsequent division doable in your head. Nobody will challenge it. Everyone will notice if you spend forty seconds long-dividing by 86,400. A few more worth having ready: 1 million requests/day ≈ 12/sec — round to 10 1 KB × 1 million = 1 GB 1 KB × 1 billion = 1 TB Peak traffic ≈ 2–3× average Replicated storage ≈ 3× raw ## Work in one direction Users → requests → QPS → storage → bandwidth. Don't jump around. Say each assumption out loud and label it as an assumption, so the interviewer can correct you early rather than watch you build on sand. A worked example Say we're designing a social feed. Given: 100M daily active users. Assumptions (stated, not smuggled in): Each user posts 0.2 times/day Each user reads their feed 10 times/day A post averages 1 KB including metadata A feed page shows 20 posts Writes 100M × 0.2 = 20M posts/day 20M / 10^5 = 200 writes/sec Peak (3×) = 600 writes/sec Reads 100M × 10 = 1B feed loads/day 1B / 10^5 = 10,0

Jotai v2.20.0 has been released, focusing on improved performance for high-throughput scenarios. Key changes involve adjustments to internal building blocks and addressing previous performance regressions. While the API for everyday use remains unchanged, library authors should note some deprecations as the groundwork for Jotai v3 begins. By Daniel Curtis

Six failed CI runs. Thirty-six hours of GitHub Actions time. Every run timing out at exactly the 6-hour limit. The culprit was one line in tests/setup.js . The Setup We were building a multi-tenant platform with a PostgreSQL backend — around 76 database models handling everything from user accounts and billing to visitor logs and real-time notifications. The test suite had grown to roughly 1,140 test cases across 36 files. Standard stuff. CI ran on every PR. Tests passed locally. And then one day, CI just... never finished. The Anti-Pattern Here's what the test setup looked like: // tests/setup.js beforeEach ( async () => { const tableNames = await getTableNames (); // 76 tables await sequelize . query ( `TRUNCATE TABLE ${ tableNames . join ( ' , ' )} CASCADE;` ); }); The intent was clean isolation — every test starts with a blank slate. Reasonable in theory. Catastrophic in practice. The Math Do the multiplication: 76 tables × 1,140 tests = 86,640 TRUNCATE operations Each TRUNCATE TABLE ... CASCADE is not a cheap operation. PostgreSQL has to: Acquire exclusive locks on all referenced tables Walk the foreign key graph to find dependent tables Truncate each in dependency order Release locks With a moderately complex schema where most tables reference others (users → societies → members → invoices → payments → ...), a single TRUNCATE ... CASCADE on a central table can fan out into dozens of implicit truncations. Multiply that by 86,640 and you have a test suite that will never complete within any reasonable timeout. Why It Wasn't Caught Sooner Two reasons: 1. It used to be fast. When the suite had 50 tests and 20 tables, this pattern worked fine. 50 × 20 = 1,000 truncations — uncomfortable but survivable. Nobody noticed when the suite crossed a tipping point. 2. Local runs used a different database state. Locally, developers often ran a subset of tests with --grep or file-specific runs. The full suite was only ever run on CI, and CI was slow enough that most assumed i