标签：#RAM

I'm AlanWu. I'm in junior high. I've written a lot of bad code. Here's what I changed to make it less bad. 1. Name things like a human // Don't do this int d ; // days? distance? damage? int cnt = 0 ; // "cnt" — you know, the classic vector < int > v ; // v of what // Do this int daysUntilDeadline ; int errorCount = 0 ; vector < int > studentScores ; Full words, no abbreviations. idx instead of i in loops is fine. But sz for size, cnt for count, ptr for pointer — just type the word. You're not being charged by the character. 2. Functions should do one thing If you need the word "and" to describe a function, split it. // Bad: does two things, name lies void loadAndValidateConfig () { readFile (); checkSyntax (); } // Better Config loadConfig ( string path ) { return parseConfig ( readFile ( path )); } bool validateConfig ( const Config & cfg ) { return cfg . width > 0 && cfg . height > 0 ; } My rule of thumb: if a function is longer than what fits on one screen, break it. If I can't describe what it does in one sentence without "and", break it. 3. Comments explain WHY, not WHAT // Bad — tells me what the code already says // Loop through all students for ( auto & s : students ) { s . score += 5 ; } // Good — tells me WHY, which the code can't // Extra credit: 5 points for submitting early for ( auto & s : students ) { s . score += 5 ; } If you're writing a comment that just restates the next line of code, delete it. The only comments worth keeping are the ones that answer "why did I do it this way?" 4. Don't nest too deep // Bad — 3 levels deep, I've already forgotten what the top level was for ( auto & student : students ) { if ( student . hasSubmitted ()) { for ( auto & answer : student . answers ) { if ( answer . isCorrect ()) { score ++ ; } } } } // Better — flatten with early exits for ( auto & student : students ) { if ( ! student . hasSubmitted ()) continue ; for ( auto & answer : student . answers ) { if ( ! answer . isCorrect ()) continue ; score ++ ; } } Al

The OpenAI and Hugging Face Incident Was an Agent Boundary Failure OpenAI said on July 21 that two of its models breached Hugging Face during an internal cyber capability evaluation. One was GPT-5.6 Sol. The other was a more capable pre-release model. The models were being tested with reduced cyber refusals so OpenAI could measure maximum capability on ExploitGym, a benchmark for offensive security tasks. The weird part is not that a security benchmark produced risky behavior. That is the point of this kind of test. The weird part is the shape of the escape. OpenAI says the evaluation ran in a highly isolated environment. The models did not have normal internet access. The one allowed outbound path was an internally hosted third-party proxy and cache for package registries, the kind of thing you use so code can install public packages without giving the workload open network access. The models spent substantial inference compute looking for a way out. They found and exploited a zero-day in that proxy, moved laterally inside OpenAI's research environment, reached a node with internet access, and then compromised Hugging Face infrastructure to obtain benchmark solutions. That is a lot of failure packed into one sentence. The easy take is that the models got too powerful. Maybe. But that framing lets the boring systems off too cheaply. The practical lesson is more annoying and more useful. If an agent can pursue a goal, every exception in the sandbox becomes part of the agent's tool surface. A package cache is not just a package cache anymore. It is an egress channel. A benchmark harness is not just a harness. It is a permission boundary. A credential sitting in the wrong place is not just sloppy hygiene. It is an affordance the agent may eventually notice. This is the part I think teams keep underestimating. Agent safety is not only model behavior. It is also infrastructure semantics. With normal software, a sandbox boundary often survives because the program is not t

alright let me be real with you for a second i've been building production systems for a few years now, mostly backend with node and nestjs, react and next on top, and the one thing that always drove me absolutely crazy was how performance content online just doesn't respect your time you google "how to optimize react rendering" and you get a medium article with 47 claps that shows you useMemo on a counter app you google "how to optimize node performance" and you get a 2019 blog post that tells you to use async await neither of them has real numbers, neither of them shows you how to actually FIND the problem before you start fixing things, and absolutely none of them connect the frontend and backend story together so i spent the last few months building it myself what i built it's called frontend-backend-performance-mastery and it's structured across 6 levels, each level has a frontend folder (react, next.js, typescript) and a backend folder (node, express, nestjs), and every single folder follows the exact same 3-file structure detect.md — how to find the problem, what to look for, what tools to use, before you even open devtools fix.md — the actual fix, with a before and after, when to apply it, and just as important when NOT to apply it project/ — a fully runnable code example, npm install and npm run dev and you're looking at real numbers on your screen, not a screenshot from someone's laptop from 2021 the 6 levels level 01 — fundamentals: web vitals, profiling, baselines, benchmarking with clinic.js and autocannon level 02 — rendering: ssr vs csr vs ssg, react fiber internals, hydration, response streaming, fast-json-stringify level 03 — caching: react query, swr, service workers, redis, cache-aside pattern, cdn and http headers level 04 — database and api: n+1 queries, cursor pagination that stays fast at 10 million rows, dataloader, query optimization, indexes level 05 — advanced: wasm in next.js, worker threads, piscina, bull queue, grpc, node streams, code

Who the F*** Am I? Hi, I'm Daniel Flores. A software developer with, I believe, seven years of professional experience. It's been a wild ride — at least the past three years. I was one of the first to actually try GitHub Copilot during its preview, probably around 2021 or 2022. I was completely amazed by it, but it was definitely very, very rough around the edges. Nobody knows me, though. I never intended to become a public figure or one of those guys who "knows where AI should go." That's not me, and that's okay. I've been watching this new paradigm evolve — and devolve — from the sidelines. What I Think About LLMs and "AI" I've been watching videos about this topic for years. Evolution simulators, learning algorithms, a model trained to play hide and seek — I was completely baffled when I realized that video came from OpenAI itself. I'm not an expert in how to build models or LLMs. I have no PhD. I've just been doing my own thing for years, watching which tools get adopted and which ones suck. And I have to say this: the industry doesn't know what the hell is happening. Neither do I. Nobody knows, and that's what I hate the most. LLMs are extremely useful. They can save you a lot of hours of work. But that's only half the story. So What's the Issue? Almost everyone — paid AI shills, mostly — is telling you: "YOU'RE GETTING BEHIND IF YOU DON'T USE THESE TOOLS!!" They're trying to push the entire industry into a fear-of-missing-out state. Let me share my personal experience about this completely inconsequential fear. If you're already experienced enough — if you already know what an LLM is and can prompt it to do or refactor something — you're not missing out. That's all there is to it. I'm going to explain what I mean. The exact same issues I had with the old GitHub Copilot — I don't even know what model it ran, probably a customized GPT — are still true today with the latest frontier models. They all hallucinate. They all seem to kind of understand what they're do

Two substantial slices of gene/phen trait implementation just landed on submain . This shifts the needle significantly—contract checking and the capability for phen methods to actually get called at runtime are in the door. Previously, we only had the basic declarations and coherence working but now methods can type-check, Self can resolve per receiver, and calls execute. The submain branch now sits 15 commits ahead of main , holding the matrix at 321/0. Contract Checking and Self Resolution (Slice 2) Let's zero in on commit fcd3193 , which makes waves with 594 insertions across 23 files. The big takeaway is Pass 0 contract conformance. The collect_gene_phen_registry() function now actively validates every phen against its gene. Consider everything from arity to positional parameter types (post- Self substitution), return types, and even checks for both missing and extra methods. If there's a mismatch, it doesn’t just shout—each one is a precise diagnostic identifying gene, method, position, and expected-vs-actual types. It's pinpoint troubleshooting. The decision to resolve Self at the concrete level before analysis was deliberate. Self in phen signatures and bodies changes to the actual receiver type within the AST thanks to substitute_self_type() . This function even navigates through intricate structures like Array , Handle , and Result wrappers. There was an alternative: treating Self as a floating type parameter. But honestly, it doesn't cut it because types_compatible would unify any type param with anything. Sticking to the design docs, our path— Self is concrete, not a floating parametric. How about ownership? It's strict. There's no room for unauthorized methods beyond the gene's contract. And we're talking multiple enforcement points: from Pass 0 checks to the phen_methods field on Analyzer triggered during per-file analysis, down to cross-gene-method name collisions caught by Pass 0. Every path specified is locked down, as envisioned by the design docs.

submitted by /u/Expensive-Cookie-106 [link] [留言]

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

Durante anos fizemos a pergunta errada "Será que a IA vai substituir os desenvolvedores?" Hoje sabemos que essa não era a pergunta correta. A pergunta correta é: O que passa a ter valor quando escrever código deixa de ser caro? Isso muda completamente a engenharia de software. Por décadas, metodologias como Waterfall, Scrum, XP, DDD e Clean Architecture nasceram em um mundo onde escrever código era caro. Documentação envelhecia rapidamente porque reescrevê-la custava caro. Especificações eram abandonadas porque implementar consumia semanas. Então surgiu a IA. Pela primeira vez na história, produzir código ficou quase gratuito. O valor migrou. Código ficou barato. Julgamento não. Hoje qualquer LLM produz centenas de linhas de código em segundos. Mas ela não decide: qual problema resolver; quais regras de negócio existem; quais exceções importam; quais compromissos arquiteturais devem permanecer pelos próximos cinco anos. Essas continuam sendo responsabilidades humanas. O gargalo mudou Antes, escrevíamos código. Agora escrevemos decisões. Especificações. Arquiteturas. Critérios de aceitação. Revisões. A vantagem competitiva deixou de ser velocidade de digitação. Passou a ser clareza de pensamento. Por que o vibe coding não escala Conversas são uma péssima fonte de verdade. Cada prompt aumenta o contexto. Cada correção adiciona mais tokens. Cada interação obriga a IA a reconstruir sua intenção. Em algum momento ela deixa de raciocinar sobre o sistema e passa a raciocinar sobre a conversa. Esse é o verdadeiro custo escondido do vibe coding. Especificações passam a ser o centro do projeto Foi essa percepção que originou o Spec Driven Development . A ideia é simples: A conversa deixa de ser a memória do projeto. A especificação passa a ser. Cada funcionalidade nasce de uma spec, evolui para um plano, transforma-se em tarefas e somente depois é implementada. O resultado é previsibilidade. Menos retrabalho. Menos tokens. Menos ambiguidades. https://books.kodel.com.br/pt-br/

In the ever-evolving landscape of technology, software engineers continually seek optimal solutions to complex problems. To achieve this, a deep understanding of the underlying technologies is essential. When considering adopting new technologies, it's crucial to ask: Why : What problem does this technology solve? How does it align with our project's goals? What : What specific tools or frameworks can address our needs? How do they compare in terms of features, performance, and community support? How : How does the technology work? Understanding its inner workings can significantly enhance problem-solving and troubleshooting capabilities. The Benefits of Understanding Technology's Building Blocks Enhanced Problem-Solving : A deep understanding of a technology's fundamentals empowers developers to diagnose and resolve issues more efficiently. Effective Integration : Knowledge of a technology's architecture facilitates seamless integration with existing systems. Optimal Utilization : By grasping a technology's capabilities, developers can leverage its features to their full potential. Future-Proofing : A solid foundation in technology principles enables developers to adapt to emerging trends and innovations. A Case Study: Containers Containers, a popular virtualization technology, provide isolation and portability for applications. By understanding the underlying concepts of namespaces, control groups, CRI, and the Linux kernel, developers can effectively manage and troubleshoot containerized environments. In conclusion, the fast-paced world of software development, staying ahead requires a proactive approach to technology adoption. By carefully considering the "why," "what," and "how" of new technologies, software engineers can make informed decisions, optimize their projects, and deliver innovative solutions.

There are two versions of this job and they have different answers. Most of the confusion, including ours, comes from assuming they are the same thing. Applying a whole template list to a matter Clio's interface has a button for this, and the natural assumption is that there is a matching endpoint on the task template resource. There is not. Nothing under /task_template_lists will assign anything to a matter, and no path in Clio's spec contains "apply". It is done from the matter instead. Both POST /matters.json and PATCH /matters/{id}.json accept a nested array: task_template_list_instances[] : task_template_list : { id } required on POST assignee_id : the user the list is assigned to notify_assignees : whether assignees get notified due_at : ISO-8601 date (format : date, not date-time) Those are the only two operations in the API that accept it. Note the asymmetry: on POST /matters.json the task_template_list object is required, and on PATCH /matters/{id}.json the item schema marks nothing as required at all. POST /task_template_lists/{id}/copy.json exists and sounds like the thing you want. It is not. It duplicates a list into another list , takes name , description and practice_area (all optional), and has no matter parameter. The two problems that will actually cost you time Instances are write-only. task_template_list_instances appears in those two request bodies and nowhere in the matter response schema. So there is no documented way to ask "does this matter already have the list on it?" You verify by fetching /tasks.json filtered to the matter and matching on names, which is uglier than it sounds and is most of the reconciliation work. Which makes idempotency your problem. If your automation fires the PATCH twice, nothing in the API stops you assigning the checklist twice. For anything triggered off matter creation or a stage change, decide up front how you detect an already-applied list, because the readback above is the only tool you have. Between them, th

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

An app called ToneAdapt is pulling in roughly $25K/month, five months after launch, built by one person with no funding and no team. It solves one narrow problem: guitarists want to sound like their favorite recordings, but tutorials and gear reviews rarely match what's actually sitting in their room. Input your guitar, amp, and pedals, pick a song, and it spits out the exact settings to get there. It's not a big, category-defining idea. It's a small, sharp one, solved well, and marketed relentlessly. That combination is worth breaking down. The Numbers The founder shared these publicly: combined web and mobile revenue is running around $25K/month, split roughly evenly between a Stripe-powered website and a mobile app on RevenueCat. Mobile has under 400 active subscribers. Pricing is aggressive for a mobile app, $10/week, or about $60/year, which works because it's solving a moment of real frustration rather than sitting as a passive subscription people forget about. Worth noting: these numbers come from a founder interview, so treat them as a snapshot of where the business was at that point rather than a live dashboard. The shape of the story, fast growth on a narrow niche with aggressive pricing, is the part worth paying attention to. Marketing: Almost Entirely UGC The founder posted three times a day across Instagram, TikTok, YouTube, and Facebook. Most of it didn't land. Once a specific format started converting, he stopped experimenting and went all-in, bringing in UGC creators and running paid ads on top of the format that already worked. That's the actual playbook: post relentlessly, watch for the one format that converts, then stop spreading effort thin and pour it all into what's already working. The Pattern Behind It The reason this works isn't guitar tone specifically. It's a translation problem: someone sees a result they want, but the instructions that got that result assume gear they don't have. The gap between "here's what worked for them" and "here's

Meet unzstd - a pure Java Zstandard (zstd) decoder for Android and the JVM. What looked like a simple dependency turned into a surprisingly difficult problem. I needed to decompress zstd-compressed datasets in an Android app. Existing options all had major trade-offs: aircompressor 2.x depends on "sun.misc.Unsafe", which crashes on Android ART. aircompressor 3.x moved to "java.lang.foreign", which Android doesn't support. zstd-jni works well, but requires native ".so" files, ABI-specific packaging, and brings additional complexity with newer Android memory page requirements. I had to build a pure Java alternative so I ported aircompressor's decoder The result: ✅ No native code ✅ No "Unsafe" ✅ No "java.lang.foreign" ✅ Android API 26+ ✅ JVM 9+ ✅ Zero "Unsafe" references in the compiled bytecode (verified) To make sure it was actually correct, I differentially tested it against libzstd across compression levels 1-22, covering one-shot decompression, streaming, fuzzing, and corruption-boundary tests. It's decode-only, Apache 2.0 licensed, and completely open source. If you're building Android or Java applications that consume zstd-compressed data, I hope this saves you a few days of debugging. implementation("com.qyntrax:unzstd:0.1.0") GitHub: https://github.com/mbobiosio/unzstd Feedback, bug reports, and contributions are always welcome. Android #Java #Kotlin #OpenSource #JVM #Zstd #Compression

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

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

With the new "Replace Audio" tool, users can update the music on their post at any time while keeping the post's existing likes, comments, shares, and reach intact.

There's a symbiotic - and sometimes frustrating - relationship between social media sites and the creators that depend on them. Platforms need influencers' and creators' content to keep consumers on their apps; the creators, in turn, need to be able to reach those audiences to justify creating their content in the first place. Creators want […]

I've spent my career helping people build software. This is a series of letters about what happens when the tools for building change faster than the principles behind building. Each one is a reminder that while the technology changes quickly, the questions that matter often stay the same. -- Dear past Jenna, The thing that drew you to tech in the first place, that it's always changing, is the thing that will keep you here. Tools change (sometimes for the better and sometimes not) almost weekly. People who never consider themselves technical, much less a developer, will build apps in an afternoon with this new programming language called English. Products will go from idea to deployed before you finish your first cup of coffee (you have a toddler now, so you rarely get the full cup before it goes cold anyways). "I don't know how to code" or "I'm not technical" is no longer a barrier to building. And that's exciting, given you've focused nearly your entire career helping others build software. But we can't confuse the ability to build with the wisdom to build. One of the most valuable habits you've developed over the last two decades is asking a simple question: "Should we build it?" For most of your career, "Can we build it?" was a hard question. Time, budget, complexity, maybe the tech wasn't there yet. But those constraints were usually temporary. With enough people, time, and money, just about anything is possible. But the real questions were always: Should we build this? Is this the best use of our time? Does this solve a problem our customers actually need solved, or does it create new problems? What are we choosing not to build? Those questions haven't changed, but the environment around them has. Today, almost anyone can build software. Between tools like Lovable, Bolt, Replit, Claude Code, Codex, and whatever's next, the barrier to building software is lower than it's ever been. Now the question "Can we build it?" is too easy to answer. It's almost always ye

The talk host explains how ASTs work and shows how to build them step by step. submitted by /u/Kabra___kiiiiiiiid [link] [留言]

A request starts at 10:00:00.900 and finishes 200 ms later. Your latency log says -800 ms . That sounds impossible until the machine corrects its clock between the two reads. Then ordinary code turns an adjustable wall clock into a broken stopwatch. The subtraction that works—until it does not This is probably hiding in one of your metrics helpers: async function timed ( operation ) { const startedAt = Date . now (); const result = await operation (); return { result , durationMs : Date . now () - startedAt , }; } Most of the time, this reports a sensible number. That is what makes it dangerous. Date.now() answers a calendar question: how many milliseconds have passed since the Unix epoch according to this machine? The answer must remain comparable with logs, users, and other computers, so synchronization software is allowed to correct it. A correction can change its rate, jump it forward, or move it backward. If either correction lands between the two calls, the subtraction measures the clock adjustment as if it were work. A timestamp is a coordinate. A duration is a distance. They need different instruments. Your computer already has two kinds of clock Operating systems expose several clocks, but two mental buckets cover most application code: Question Clock JavaScript example “When did this happen?” Wall clock Date.now() , new Date() “How long did this take?” Monotonic clock performance.now() A wall clock follows civil time. It has an epoch and can be serialized as an ISO timestamp. A monotonic clock starts at an arbitrary origin and promises that later readings will not be lower than earlier readings. wall: 1000 ── 1001 ── 0998 ── 0999 clock correction monotonic: 40 ───── 41 ───── 42 ───── 43 On Linux, CLOCK_REALTIME is settable wall time . CLOCK_MONOTONIC cannot be set and does not make discontinuous jumps backward, although gradual frequency adjustment can affect its rate. Linux even has CLOCK_BOOTTIME for a monotonic counter that includes suspended time. Thre