今日已更新 135 条资讯 | 累计 24421 条内容
关于我们

标签:#t

找到 11699 篇相关文章

AI 资讯

Understanding the Building Blocks of Technology

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.

2026-07-22 原文 →
AI 资讯

Let'sDefend SOC166 - Javascript Code Detected in Requested URL Investigation Wlakthrough

When we first look at the requested URL in the investigation channel , we can see that "script" and "alert" js code was added to the request , so we can see that an attempt for an XSS attack was made. Then , we want to check whether the source ip adress is malicious or not by using VirusTotal or AbuseIPDB. After checking the source ip adress , we can see the ip adress belongs to an internet provider service in China and marked as malicious on boh sites. After that, we check the destination ip adress on the same sites and see that the ip adress belongs to a company network , so we can say that the traffic was from internet to company network. Then , we go to the "Log Management" section to see if we can see any logs from the source ip adress and when we check , there are 8 requests that were made at the time of event to the same destination ip adress and even though the http response status was "200" for 7 of these requests , the last request's status code was "302" so we can see that the attack was unsuccessful. Later on , we check the "Email Security" section and see there isnt any planned tests. We go to the "Endpoint Security" section to contain the " WebServer1002" server to prevent any further damage.

2026-07-22 原文 →
AI 资讯

I Built the First Collaborative Multi-Persona Sandbox (Because I'm Sick of Cloud Wrappers)

Most AI “apps” these days aren’t really apps. They’re wrappers. A thin UI. A subscription. A cloud call. A monthly fee. And your data quietly piped off to a server farm you’ll never see. I didn’t want to build another one of those. I didn’t want to use another one of those. So, I built something different. I built Bob’s Bar — the first Collaborative Multi-Persona Sandbox (CMPS). Let's be honest, every AI chat feels the same. You ask a question, it answers, repeat. Useful? Yes. Alive? No. I kept thinking: “Why does every AI tool assume I want a one-on-one conversation? Why can’t multiple AIs talk to each other while I watch?” That question became the seed. I wanted a space where multiple personas could exist together, talk to me and each other, and run entirely on my own hardware. I’m an indie dev. I don’t have a server farm, and I don’t want to pay AWS just to host my own brainstorming sessions. So the architecture is 100% local-first: -Engine: Ollama (raw LLM inference) -UI: Python + Gradio (Blocks API for stateful UI) -Distribution: PyInstaller → standalone .exe -Licensing: Lemon Squeezy API (so I could actually sell the damn thing) No cloud. No subscriptions. No data scraping. Just your machine doing the work. But getting four local models to talk to each other without hallucinating is absolute chaos. At first, they spoke twice in a row. They impersonated each other. They put words in the user’s mouth. They derailed into movie scripts. Vane pitched a heist film, and Bob started giving stage directions like “I polish a glass and chuckle.” I had to build what I now call The Bouncer — a regex-powered clean_reply() function that physically chops off AI responses the moment they write a script, impersonate another persona, use bullet points, or hijack the conversation. I also added a seen_in_banter set to prevent any persona from dominating the room. Once the routing was locked down, the magic happened. Because the AIs share a context window, emergent behaviour happen

2026-07-22 原文 →
AI 资讯

Why your Clio token stopped working

If your Clio integration started returning 401 and you are trying to work out why, the first question is not about your code. It is which of Clio's two OAuth systems you are on, because they have different rules and most advice on the internet does not say which one it is describing. There are two, and they are not interchangeable Clio Manage is the older one. OAuth at app.clio.com/oauth , API at app.clio.com/api/v4 . Clio Platform is the newer one, covering Grow and the lead inbox among others. OAuth at auth.api.clio.com/oauth , API at api.clio.com . They differ on essentially every point that matters when a token dies. Manage Platform Access token lifetime 2,592,000s, 30 days 86,400s, 24 hours Refresh token expiry Documented as none No time expiry, but rotates Refresh token rotation Not documented, and the refresh sample returns no new refresh token Documented: rotates on every use, previous one revoked Revocation endpoint POST app.clio.com/oauth/deauthorize , Bearer auth POST auth.api.clio.com/oauth/revoke , Basic auth Treat the lifetime row as the documented default rather than a constant. Honour the expires_in you get back on each response instead of hardcoding 30 days, because there are field reports of accounts issuing much shorter access tokens, and a hardcoded assumption fails in a way that looks exactly like revocation. That rotation row is the one that decides your debugging. On Platform , every refresh gives you a new refresh token and kills the old one, so failing to persist the new value out of each response leaves you holding a dead token the next time you try. Clio's docs say it directly: store the new refresh token returned in each response. On Manage , the documented behaviour is a long-lived refresh token that does not expire and is not replaced. Their refresh response sample does not even include a refresh_token field. So on Manage, a token that suddenly stops working usually points somewhere else: revocation, or the wrong region. The region trap

2026-07-22 原文 →
AI 资讯

How to apply a Clio task template to a matter through the API

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

2026-07-22 原文 →
产品设计

The First Computer Bug Was a Real Moth

If you have ever stared at a misbehaving circuit at two in the morning, muttering about the "bug" you cannot find, you are part of a lineage that runs back to a very literal insect. On September 9, 1947, engineers working on Harvard's Mark II computer opened up the machine, found a moth wedged inside a relay, and taped it into their logbook. The note beside it reads: "First actual case of bug being found." It is one of the most charming artifacts in the history of computing, and it carries a surprisingly practical lesson for anyone who builds connected hardware today. What actually happened in 1947 The Mark II was an electromechanical monster: a room-sized calculator built from thousands of relays, switches that physically clacked open and closed to represent ones and zeros. On that September day the machine was producing errors, and the operators -- part of the U.S. Navy computing effort that Grace Hopper worked in -- traced the fault to Relay #70 in Panel F. Inside was a moth, its wings shorting across the contacts. They removed it, taped it into the logbook at 15:45, and recorded the now-famous line. That page, moth still attached, lives today in the Smithsonian's National Museum of American History. Hopper loved telling the story for the rest of her career, which is why her name is forever attached to it. She is often credited with coining "bug" and "debugging" because of that moth, but the honest history is a little different, and the difference is the interesting part. The word "bug" was already old Engineers had been calling faults "bugs" for decades before 1947. Thomas Edison used the term in an 1878 letter to describe the little glitches and "difficulties" that show up when a new invention meets the real world. By the early twentieth century "bug" was common shop-floor slang among electrical and telephone engineers. So the moth did not invent the word. What made the logbook entry so memorable is the joke buried in it: "first actual case of bug being found"

2026-07-22 原文 →
AI 资讯

AI and the rise of the universal entertainment app

Over the past decade, streaming platforms competed by dominating individual formats like music, video, podcasts, or audiobooks. Now, as AI makes it easier to create, organize, and recommend content, those distinctions are fading, pushing companies like Spotify, Netflix, YouTube, and TikTok to become all-purpose entertainment destinations instead.

2026-07-22 原文 →
AI 资讯

Android Studio Quail 2 Redesigns Agent Mode, Streamlines AI-Assisted Coding

The latest release of Android Studio, Quail 2, now stable, expands Gemini/AI Agent Mode inside the IDE by enabling multiple AI conversations in parallel and further advancing Google's push to integrate AI-powered workflows directly into Android Studio. It also enhances debugging and profiling capabilities and makes it easier to explore experimental features. By Sergio De Simone

2026-07-22 原文 →
AI 资讯

A resumable, human-in-the-loop AI agent in ~200 lines with zero dependencies

Most "AI agent" libraries fall into one of two buckets. Either they're a big framework you spend an afternoon configuring, or they're a tiny toy that drops the one feature you actually need in production: the ability to stop and ask a human before the agent does something you can't undo. I wanted the middle. So I wrote yieldagent : a small agent loop you can read end to end, with human-in-the-loop pause/resume built in, and no runtime dependencies. This post walks through how it works and why it's built the way it is. What an agent loop actually is Strip away the branding and an "agent" is a loop: Send the conversation to the model, along with the tools it's allowed to call. If the model asks to call a tool, run it and append the result. Repeat until the model answers without asking for a tool. That's it. The model decides the control flow at runtime; your job is to run the tools and feed the results back. Here's the core, lightly trimmed: for ( let step = 0 ; step < maxSteps ; step ++ ) { const reply = await call ( messages , toolSpecs ); messages . push ( reply ); if ( ! reply . tool_calls ?. length ) { yield { type : " final " , text : reply . content , messages }; return ; } for ( const tc of reply . tool_calls ) { const args = JSON . parse ( tc . function . arguments ); const result = await tools [ tc . function . name ]. run ( args ); messages . push ({ role : " tool " , tool_call_id : tc . id , content : JSON . stringify ( result ) }); } } Everything else in the library is in service of making this loop observable, testable, and safe to run against the real world. Why an async generator Notice the yield . The loop is an async generator, so the caller drives it: for await ( const step of agent ({ call , tools , messages })) { if ( step . type === " tool-start " ) console . log ( " -> " , step . tool , step . args ); if ( step . type === " final " ) console . log ( step . text ); } Every step (each tool call, each result, and the final answer) is handed back to

2026-07-22 原文 →