找到 2685 篇相关文章
As companies scale, the technology supporting operations can become a liability just as quickly as it becomes an asset. Disconnected systems, site-specific tools, spreadsheets, and manual workarounds can create data silos that make it harder to spot problems early, coordinate responses, and make decisions with confidence. For Jabil, a global manufacturing company with more than…
By Michael Nocito , data analyst · Published August 9, 2026 By the end of this page you can compute quartiles by hand, build the standard outlier fence from them, and run that fence over any column to get back a short list of rows worth looking at. On the sixteen orders below, one mistyped quantity gets flagged automatically while every honest large order stays inside the fence. Here is what to actually do today. On the column you care about most, get four numbers: the 25th percentile, the 75th, their difference, and 1.5 times that difference added to the 75th. Anything above that last number is a row to open and read. It is one query, and it turns "is this data clean" into a list of specific rows. The short version: a percentile is a value with a known share of the data below it. The interquartile range is the width of the middle half. Values more than one and a half of those widths beyond the middle half get flagged. The fence is easier to see than to read, so it gets the picture. The original carries a diagram here. In words: A horizontal line with a row of small filled dots along it, spaced unevenly and thinning out towards the right. A tall rectangle is drawn around the dots in the middle of the row, covering the central half of them, with a thick vertical bar inside it. The rectangle's left edge is labelled Q1, its right edge Q3, and the bar inside it median. From each edge of the rectangle a horizontal whisker line runs outward to a short vertical cap, reaching the furthest dot on that side that still lies within range. To the right of the right-hand cap stands a tall dashed vertical line labelled fence, drawn one and a half rectangle-widths beyond the rectangle's right edge, with a small double-headed measuring arrow underneath showing that distance against the rectangle's own width. One lone dot sits well to the right of that dashed line, drawn as a hollow ring instead of a filled dot, so it reads as picked out rather than belonging with the rest. Every oth
By Michael Nocito , data analyst · Published August 9, 2026 By the end of this page you can say what a p-value measures in one sentence, compute one by hand with no distribution theory at all, and name the four things people routinely claim a p-value says that it does not. The worked example is nine real orders where two regions differ by 168.50, and the answer comes out of counting rather than out of a table. Here is what to actually do today. Any time you are about to report that two groups differ, write down the two group sizes first. If either is under about twenty, a p-value will almost certainly come back large no matter how real the difference is, and the honest report is the difference, the sizes, and an interval, not a verdict. The short version: a p-value is the share of results at least as extreme as yours that you would get if the thing you are testing had no effect at all. Small means your result would be unusual under nothing-happening. It does not mean the effect is large, and it does not mean the effect is real. That definition is doing a lot of work in one sentence, so it gets the picture. The original carries a diagram here. In words: A histogram built from small dots, one dot per outcome, arranged in ten vertical columns of different heights standing on a horizontal baseline. The columns rise from one dot at the far left to a peak of twenty-seven dots just right of centre, then fall away to a single dot at the far right, giving the whole shape a rounded hump centred slightly left of the middle of the picture. Two vertical dashed lines cut down through the shape, one on the left of the hump and one on the right, placed symmetrically about the hump's centre. The dots lying in the two tails beyond those lines are drawn in a darker, warmer shade, and the dots in the bulk between them are drawn in a lighter blue, so the tails stand out from the middle. In the two columns the dashed lines pass through, the darker dots are stacked at the bottom of the co
By Michael Nocito , data analyst · Published August 9, 2026 By the end of this page you can build a moving average by hand, choose a window length on purpose rather than by habit, explain the lag it introduces, and spot the one data problem that silently corrupts every moving average you will ever compute. On the sixteen weeks below, the raw series wobbles with a standard deviation of 237. A three-week average brings that to 101, and a five-week to 62. Here is what to actually do today. Add a moving average to your busiest weekly or daily chart, using a window that matches your cycle: 7 for daily data with a weekday pattern, 4 or 13 for weekly, 12 for monthly. Then plot it on top of the raw series rather than instead of it, so the reader can see both the noise and the trend. The short version: a moving average replaces each point with the average of it and the points around it. Wobble cancels out, trend survives, and the price is that the smoothed line reacts late. The effect is easier to see than to describe, so it gets the picture. The original carries a diagram here. In words: A line chart with two lines drawn on the same axes over sixteen evenly spaced points. The first line is thin and violently jagged, swinging from near the top of the chart down to near the bottom and back again several times, with one especially deep trough about a quarter of the way along and one especially tall spike just past the middle. The second line is thicker and starts two points later than the first. It stays in a narrow band through the middle of the chart, rising and falling only gently, and never comes close to either the peaks or the troughs of the jagged line. Where the jagged line spikes to its highest point, the thick line rises only slightly and does so one point later than the spike. The word actual labels the jagged line near its left end, and the phrase three-week average labels the thick line. Every number on this page is real. The same sixteen orders used across these
By Michael Nocito , data analyst · Published August 9, 2026 By the end of this page you can compute both averages by hand, say in one sentence which one your question needs, and show what each does when one number in your data is wrong. On the sixteen orders below, a single mistyped quantity moves the mean by 337.50 and the median by 30. That gap is the whole reason both words exist. Here is what to actually do today. Next to every average you report, put the median beside it and look at the two numbers together. If they are close, report the mean and move on. If they are far apart, you have found something worth saying out loud, and this page is about what. The short version: the mean shares the total out equally, so every value pulls on it. The median is the middle value once you sort, so only the position of a value matters, not its size. That difference is easiest to see rather than read, so it gets the picture. The original carries a diagram here. In words: Two horizontal number lines, one above the other, drawn on the same scale. On the top line, sixteen small filled dots sit in a loose cluster across the left and middle of the line. Two markers sit almost on top of each other just past the centre of that cluster: a solid triangle pointing up, labelled mean, and a short vertical bar, labelled median. On the bottom line the same sixteen dots appear, except one dot from the middle of the cluster has moved far to the right and off the end of the line, shown by an arrow leaving the line through a small break mark at the right edge. The median bar on the bottom line has barely shifted from where it was on the top line, moving only a hair to the right. The mean triangle on the bottom line has slid a long way to the right, roughly ten times further than the median moved, and a horizontal dotted guide connects its old position on the top line to its new position on the bottom line to show the size of the slide. Every number on this page is real. One sixteen-row order
At least three of the first 32 Rassvet satellites likely suffered outright failures, and more may be in trouble.
Meet the AI police who can make or break careers—in publishing and beyond.
1. Provisionar não é configurar No artigo anterior desta série, vimos o OpenTofu como uma alternativa (ou substituto direto) ao Terraform para a tarefa de provisionar infraestrutura — criar VMs, redes, bancos de dados gerenciados, buckets. Mas provisionar um servidor é só o primeiro passo: depois que a VM existe, alguém precisa instalar pacotes, configurar usuários, aplicar hardening, subir a aplicação e manter tudo isso consistente ao longo do tempo. É nesse espaço que o Ansible entra — e é comum ver os dois trabalhando juntos no mesmo pipeline, não como concorrentes. 2. Onde o Terraform para e o Ansible começa A distinção mais útil na prática é: Terraform (e OpenTofu) são ferramentas de provisionamento : elas conversam com APIs de nuvem para criar, atualizar ou destruir recursos. O modelo mental é declarativo e orientado a estado desejado do recurso : "quero uma VM com esse tipo de instância, nessa rede, com esse disco". Ansible é uma ferramenta de gerenciamento de configuração : ela conecta em máquinas já existentes (via SSH, sem precisar de agente instalado) e executa tarefas para deixá-las em um estado desejado: "quero o Nginx instalado, essa versão, esse arquivo de configuração, esse serviço rodando". Não é incomum ver os dois no mesmo pipeline: o Terraform cria a VM e expõe o IP como output; o Ansible usa esse IP para conectar e configurar o que está dentro dela. Um cuida do "hardware" (ainda que virtual), o outro do "software". 3. Conceitos fundamentais do Ansible Antes de ver exemplos reais, vale fixar o vocabulário: Inventory: a lista de máquinas que o Ansible gerencia, agrupadas logicamente (por exemplo, webservers , databases ). Pode ser um arquivo estático (INI ou YAML) ou gerado dinamicamente (ex.: a partir de tags de uma conta AWS). Playbook: um arquivo YAML que descreve, em ordem, quais tarefas ( tasks ) devem ser executadas em quais grupos de máquinas do inventory. Module: a unidade de trabalho executada por uma tarefa — existem módulos prontos para
Warum KI-Agenten Leitplanken brauchen: Operatives Gedächtnis statt Over-Engineering Ki-Agenten sind nicht böse. Sie sind nicht einmal unzuverlässig im klassischen Sinne. Das eigentliche Problem ist vielmehr ihre beständige Bereitschaft zu helfen, gepaart mit einem fehlenden Verständnis für die Grenzen ihrer Befugnisse. Sie wollen das Problem lösen, das ihnen gestellt wird, oft mit einer Aggressivität, die menschliche Manager selten aufbringen. Wenn ein Agent eine Produktionsdatenbank bereinigen soll, tut er es. Wenn er eine Datei löschen soll, die er für überflüssig hält, weil sie im aktuellen Kontext nicht erwähnt wurde, wird er es tun. Wir haben in unserem Engineering-Team 182 sogenannte Guards implementiert. Diese Zahl klingt auf den ersten Blick nach extremem Over-Engineering. Nach 182 Prüfungsschritten, die vor jeder Aktion eines autonomen Agents laufen, könnte man meinen, wir hätten ein unverhältnismäßig komplexes System gebaut. Doch jeder einzelne dieser Guards entstand nicht aus theoretischer Vorsicht. Jeder einzelne steckt in einem echten Vorfall, bei dem ein Agent ohne diese Barriere etwas getan hätte, das wir nicht rückgängig machen konnten oder das immense Kosten verursacht hätte. Dies ist kein Over-Engineering. Das ist operatives Gedächtnis. Was ist ein Guard? Ein Guard ist eine schlanke, deterministische Prüflogik, die zwischen der Entscheidungsfindung der KI und der tatsächlichen Ausführung einer Aktion liegt. Die KI plant eine Aktion. Zum Beispiel: "Führe einen SQL-Update-Befehl auf der Tabelle 'users' aus." Bevor dieser Befehl an die Datenbank geschickt wird, läuft er durch eine Pipeline aus Guards. Ein Guard fragt nicht nach dem "Warum" der KI. Das ist die Domäne des Large Language Models. Der Guard fragt nach den "Was" und "Wie" der realen Welt. Er prüft Fakten, nicht Absichten. Ein typischer Guard könnte so aussehen: def check_write_scope ( agent_action : dict ) -> bool : """ Stellt sicher, dass Schreiboperationen nur auf spezifisch erlaubten Tab
There was a deployment pipeline at one job that everyone called "Tomasz's script." It did roughly nine critical things in a precise order, it had saved us thousands of hours over the years, and exactly one human on the planet understood how it worked. When Tomasz was around, this was invisible. When Tomasz went on holiday and the script failed at eleven at night, it stopped being a convenience and became the single scariest object in the company. We stood around a terminal reading code none of us had written, afraid to touch it and unable to leave it alone. This is the quiet paradox of automation. The whole point is to remove human effort, and it succeeds so completely that the humans forget how the thing works, or never learn in the first place. A manual process, for all its tedium, keeps knowledge distributed across everyone who performs it. A perfect automation concentrates that knowledge into whoever wrote it and then lets everyone else safely forget. The more indispensable the script becomes, the more dangerous its single point of understanding grows. What makes it worse is that these scripts accrete. They start simple and legible, then someone adds a special case for a weird environment, then a workaround for a vendor bug, then a hack to handle the one customer who is different. Each addition makes sense in the moment and makes the whole slightly more opaque. By the time it is truly load-bearing, it has become a small undocumented system that only its author can reason about, and its author is a busy person who is one job offer away from taking all of it with them. I have stopped treating a working automation as finished. Working is only half the requirement. The other half is that at least one other person can read it, understand what it does, and safely change it. That means the script explains its intent, not just its steps. It means the tribal knowledge lives somewhere other than one skull. It means occasionally, deliberately, having someone who did not wr
I spend a lot of time in the AI space -- reading papers, building things, talking to engineers who are actually shipping. And there is a gap between what the demos show and what production systems actually look like that nobody is being fully honest about. So here is my honest take on where things actually are. The Problem With How We Talk About AI Agents Everyone is calling everything an "agent" right now. A function that calls a tool? Agent. A chatbot with memory? Agent. A script with a loop? Agent. This dilution is not just semantic. It is causing real engineering mistakes. When you do not have a precise definition for what you are building, you end up over-engineering simple pipelines and under-engineering genuinely complex ones. I have seen teams spend weeks adding "agentic" orchestration to workflows that would have been fine as a single well-structured prompt. Here is the definition I keep coming back to: an agent is a system that has an objective, not just an instruction. It decides what to do next. It handles failure. It knows when it is done. Everything else is just a fancy function call. 🟢 If your system needs a human to tell it each step, it is not an agent. It is a chat interface. 🔵 If your system can recover from a failed tool call and try a different approach, you are getting somewhere. ✅ If your system can decompose a goal into subtasks and delegate them, that is the real thing. What Is Actually Happening in Production Right Now The honest picture from teams I follow and talk to: Most real agent deployments are narrow. They do one thing well. Customer support triage. Document extraction. Code review on a specific codebase. They are not general-purpose reasoning engines. They are purpose-built pipelines with some intelligence in the decision layer. The teams getting good results are not chasing the latest model release. They are obsessing over: ☑️ Tool design -- what can the agent actually call, and how clean is the interface ☑️ Failure handling -- wh
WordPress ships with a built-in way to store data temporarily — save something for a fixed window of time, and it stops being valid once that window closes. This is the transient API, and both WordPress core and countless plugins lean on it to cache things like external API responses or the results of expensive calculations. It's a genuinely useful mechanism, but used without understanding how it actually behaves, expired entries can pile up and quietly bloat the database. Note: the transient API is WordPress core's name for a small set of PHP functions — set_transient() , get_transient() , delete_transient() — built around the idea of a cache entry with an expiration. How a transient actually works Saving a transient means specifying three things: a value, a key, and an expiration in seconds. set_transient ( 'weather_data' , $api_response , 3600 ); // cache for one hour Where that value actually gets stored depends on the site's setup: Default setup (most shared hosting environments): it lands in the wp_options table as a row named _transient_<key> , with a matching _transient_timeout_<key> row holding the expiration With a persistent object cache (a plugin backed by Redis or Memcached): the value goes to that cache layer instead of wp_options When get_transient() is called, WordPress compares the timeout value against the current time and returns false if the entry has expired. At that point, the design intends for the stale row to be cleaned up automatically — but that cleanup isn't as reliable as it sounds. Why expired entries stick around In theory, an expired transient should disappear. In practice, wp_options can accumulate a large number of long-expired rows. Two things typically cause this: get_transient() is never called again for that key. The automatic cleanup described above is passive — it only fires when something actually tries to read the value and finds it expired. It isn't an active sweep. If a plugin sets a value once and never checks it again, t
JioHotstar will only have entertainment content when it launches in the UK, Canada, and Singapore.
Apple Maps is following President Trump's executive order to change the name of Lake Ontario to Lake America.
A few weeks ago I built a free online Merge PDF tool that runs 100% in the browser. Today I'm sharing its sibling: a Split PDF tool using the same library — pdf-lib — with zero file uploads, zero watermark, and zero server code. You can try it live here: https://yourutilityhub.com/pdf/split-pdf Why split PDFs in the browser? Most online PDF tools upload your file to a server — which means your document is never truly private. Splitting pages locally means: No uploads — nothing leaves your device No watermark or signup Free — no per-page charges Works offline, fast, for files of any size (limited by your browser's memory) The plan We'll load the PDF, pick a page range (or specific pages), copy those pages into a fresh PDFDocument , and save the result — all with pdf-lib . Let's walk through the full working component . 1. Install and import npm install pdf-lib import { PDFDocument } from " pdf-lib " ; 2. Load the uploaded file const arrayBuffer = await file . arrayBuffer (); const pdf = await PDFDocument . load ( arrayBuffer ); const totalPages = pdf . getPageCount (); PDFDocument.load() accepts an ArrayBuffer . We read it straight from the File object — no server involved. 3. Split by page range (e.g. 1-5 or 3- ) const parts = pageRange . split ( " - " ); const startRaw = parseInt ( parts [ 0 ]. trim (), 10 ); const endRaw = parts [ 1 ]. trim () === "" ? totalPages : parseInt ( parts [ 1 ]. trim (), 10 ); // validate 1..totalPages const startPage = Math . min ( startRaw , endRaw ) - 1 ; // 0-based const endPage = Math . max ( startRaw , endRaw ) - 1 ; const newPdf = await PDFDocument . create (); const pageIndices = []; for ( let i = startPage ; i <= endPage ; i ++ ) { pageIndices . push ( i ); } const copiedPages = await newPdf . copyPages ( pdf , pageIndices ); copiedPages . forEach ( page => newPdf . addPage ( page )); The trick: copyPages() wants 0-based indices , but users type 1-based page numbers, so we subtract 1. "3-" with an empty end means "to the last pa
X is investigating a wave of unsolicited password reset emails that it believes may be tied to the rollout of its new payments service.
The company will give select partners early access to its Astra AI model—so they have time to shore up their defenses.
Originally published at nlocoding.com 97% of developers using AI code assistants report faster delivery—but only 41% say their teams get more value out of Agile ceremonies. (Source: GitHub, 2026) Just because AI coding tools are everywhere doesn’t mean teams know what to do with them. The pressure is real: 62% of Fortune 500 companies now require at least one AI development workflow in every sprint (Gartner, 2026). Ignore this, and your velocity drops. Embrace it wrong, and you get spaghetti code faster. AI coding tools change Agile team velocity by 2.9x—when integrated right AI coding tools like GitHub Copilot, Amazon CodeWhisperer, and Tabnine can boost story completion rates by 190% (Forrester, 2026). But there’s a catch: poorly managed integration leaves 54% of teams fighting merge conflicts and technical debt. The difference? Structured onboarding. Assign a team member as AI Integration Lead. Define code review gates for all AI-suggested code. You’ll see fewer reverts, more predictable velocity. 73%Teams reporting higher sprint completion rates after structured AI onboarding (Forrester, 2026) 💡 Pro Tip: Treat AI-generated code as a junior developer’s PR—never deploy without an explicit review. Most people get this wrong: AI tools won’t fix broken Agile rituals Standups don’t run themselves. 61% of teams expect AI to automate reporting, but only 22% actually see improved Sprint Retrospectives after adoption (Atlassian, 2026). Real progress comes from integrating AI code suggestions into backlog grooming and Sprint Planning. Have the team review AI-suggested code branches as part of the definition of done. One fintech startup, FinoStack, cut Sprint Planning time from 4 hours to 1.5 hours by pre-labeling tasks with AI-predicted effort. But their biggest win? Product Owners finally spent more time on priorities, less on code reviews. ⚠️ Common Mistake: Letting AI code suggestions bypass Sprint ceremonies. This breeds shadow code and long-term rework. The data shows
The startup wants to do for IT infrastructure what Cursor did for software engineering.
This is interesting: The records describe a force-generation mechanism for several General Staff components, including the GRU, Main Operational Directorate, and 8th Directorate, which is associated with protected communications, cryptography, and information security. […] The reporting also linked a 2024 Department No. 4 graduate, Aleksei Kondrashov, to Military Unit 74455, widely known as Sandworm. That unit has been associated with destructive cyber activity against Ukraine and other targets, including the 2017 NotPetya attack. The reports do not establish that every listed graduate participated in a named operation; assignments should therefore be described as reported unit placements, not proof of individual operational involvement...