标签：#learn

I often see people using the term "namespace" incorrectly. Even when explanations of what a namespace is are presented, they only go as far as describing its function, neglecting to properly define the name "namespace" itself. Definition of the Namespace A namespace is literally the space to which a name belongs . If we were to classify the term namespace, it would be a specification (concept), not a tool. In namespaces, the higher level is represented as outer and the lower level as inner . In terms of class structure, this corresponds to outer classes and inner classes. In other words, to explain it from a different perspective, it looks like this. Representation of namespaces from the outer perspective Build namespaces (best) Define namespaces (to fit many programming language implementations) Open namespaces (such as Ruby's class definition and module definition ) Create namespaces (such as the pseudo-namespace hack in older JavaScript) Declare namespaces (such as the package declaration in Java or the namespace declaration in PHP) Representation of namespaces from the inner perspective Belong to a namespace (best) Entering the namespace (This is entirely from an inner perspective, so it might feel out of place depending on the context) Be included in the namespace (this is a reasonable explanation if explained objectively). Incorrect expression From the definition above, it is clear that the following expressions are incorrect. Add/Paste a namespace (the expression "add/paste a space" is grammatically incorrect). Use namespaces (not to the point of being completely broken, but treating namespaces as a tool) Separate/Cut namespaces (While "Separated by namespaces" is understandable, "separate/cut" can be misleading) Meaning of "Name" in Namespace The "names" referred to here can be class names, module names, or package names. What they represent varies depending on the language that implements namespaces. For example, in Ruby, it refers to constant names. In Rub

Introduction Artificial Intelligence has moved from being an experimental technology to becoming a core component of modern software systems. Companies today are integrating AI into customer support, analytics, automation, healthcare, finance, education, and enterprise applications. However, as organizations start building AI-powered solutions, one major question appears: “How do we make an AI model work specifically for our business needs?” Many teams immediately assume they need to train their own AI model. Others believe a well-written prompt is enough. Some organizations invest heavily in fine-tuning without understanding whether it is the right approach. The reality is that there is no single solution. Modern AI development usually revolves around three major strategies: Prompt Engineering Retrieval-Augmented Generation (RAG) Fine-Tuning Choosing the wrong approach can lead to higher costs, poor AI performance, security issues, and unnecessary complexity. This article explains the differences between these approaches and how businesses can select the right AI strategy. The Problem: Making General AI Models Business-Specific Large Language Models (LLMs) such as GPT, Claude, Gemini, and Llama are trained on massive amounts of publicly available data. They are excellent at: Understanding language Generating content Writing code Answering general questions Summarizing information ** However, businesses usually need AI systems that understand:** Internal company documents Customer information Product knowledge Industry-specific terminology Private databases Business processes For example: A hotel company wants an AI assistant that can answer: “What is our cancellation policy for premium customers?” A general AI model does not know this information because it was never trained on the company’s private policies. So the challenge becomes: How do we customize AI without rebuilding an entire model from scratch? This is where Prompt Engineering, RAG, and Fine-Tuning come

Full title: [Advanced Rust] 2.3. API Design Principles of Unsurprising Pt.3 - Implementing serde Serialize and Deserialize Traits, and Why Copy Is Not Recommended 2.3.1. It Is Recommended to Implement Serialize and Deserialize in serde Serde is the core Rust library for serialization and deserialization : Serialization : converts a Rust struct or enum into a string or binary representation such as JSON or YAML Deserialization : parses a string or binary representation such as JSON or YAML back into a Rust struct or enum Serialize and Deserialize are both traits from the serde crate. Serialize Trait The Serialize trait allows a type to be converted into a serializable data format such as JSON, YAML, or TOML. Its main methods include: serialize_bool serialize_i32 serialize_str serialize_struct These are methods on the Serializer (and related) traits that a Serialize implementation calls; the Serialize trait itself only requires serialize . Its definition is: pub trait Serialize { fn serialize < S > ( & self , serializer : S ) -> Result < S :: Ok , S :: Error > where S : Serializer ; } Here is an example showing how to implement Serialize manually: use serde :: ser ::{ Serialize , SerializeStruct , Serializer }; struct Point { x : i32 , y : i32 , } impl Serialize for Point { fn serialize < S > ( & self , serializer : S ) -> Result < S :: Ok , S :: Error > where S : Serializer , { let mut state = serializer .serialize_struct ( "Point" , 2 ) ? ; state .serialize_field ( "x" , & self .x ) ? ; state .serialize_field ( "y" , & self .y ) ? ; state .end () } } serializer.serialize_struct("Point", 2)? creates a struct serializer state, and 2 is the number of fields state.serialize_field("x", &self.x)? serializes the struct fields one by one state.end() finishes serialization Deserialize Trait The Deserialize trait allows Rust types to be parsed from various data formats. Its main methods include: deserialize_bool deserialize_i32 deserialize_string deserialize_struct These are

Full title: [Advanced Rust] 2.2. API Design Principles of Unsurprising Pt.2 - Implementing Clone, Default, PartialEq, PartialOrd, Hash, Eq, and Ord 2.2.1. It Is Recommended to Implement the Clone Trait and the Default Trait Clone Trait The Clone trait in Rust allows an implementer to explicitly create a deep copy of itself through the clone method, as opposed to the by-value copy provided by the Copy trait. Example: #[derive(Debug, Clone)] struct Person { name : String , age : u32 , } impl Person { fn new ( name : String , age : u32 ) -> Self { Self { name , age } } } fn main () { let person1 = Person :: new ( "John" .to_owned (), 25 ); let person2 = person1 .clone (); println! ( "{:?}" , person1 ); println! ( "{:?}" , person2 ); } The Person struct implements the Clone trait In main , person2 clones the data from person1 because it implements Clone Output: Person { name: "John", age: 25 } Person { name: "John", age: 25 } Default Trait The Default trait in Rust allows a type to define a default value and return that default instance through the default() method. Example: #[derive(Default)] struct Point { x : i32 , y : i32 , } fn main () { let p = Point :: default (); println! ( "Point is at ({}, {})" , p .x , p .y ); } Output: Point is at (0, 0) 2.2.2. It Is Recommended to Implement the PartialEq , PartialOrd , Hash , Eq , and Ord Traits PartialEq Trait PartialEq provides support for the == and != operators, allowing custom types to participate in partial equality comparisons. Example: #[derive(Debug, PartialEq)] struct Point { x : i32 , y : i32 , } fn main () { let point1 : Point = Point { x : 1 , y : 2 }; let point2 : Point = Point { x : 1 , y : 2 }; let point3 : Point = Point { x : 3 , y : 4 }; println! ( "point1 == point2: {}" , point1 == point2 ); println! ( "point1 == point3: {}" , point1 == point3 ); } By implementing PartialEq , we can compare whether two structs are equal Output: point1 == point2: true point1 == point3: false PartialOrd , Eq , and Ord Trait

You loaded an image, got a tensor shaped (batch, height, width, channels) , and your convolution wants (batch, channels, height, width) . Stack Overflow says permute . Someone else says transpose . And reshape(2, 3, 28, 28) gives you the right shape too — so why is everyone making this complicated? Because two of those three are the same tool, and the third one silently destroys your data. The short answer transpose(dim0, dim1) swaps exactly two dimensions. permute(...) reorders all of them in one call, and you must list every dimension. transpose is a special case of permute . Both return a view — no data is copied, only the strides change — which also means both leave you with a non-contiguous tensor. reshape is not in this family at all. It reinterprets the flat memory under a new shape without moving anything, so it can produce the shape you asked for while completely scrambling what the numbers mean. import torch t = torch . arange ( 24 ). reshape ( 2 , 3 , 4 ) print ( t . transpose ( 0 , 1 ). shape ) # torch.Size([3, 2, 4]) — swapped dims 0 and 1 print ( t . permute ( 2 , 0 , 1 ). shape ) # torch.Size([4, 2, 3]) — full reorder transpose — swap two axes transpose(dim0, dim1) takes two dimension indices and swaps them. Everything else stays put. t = torch . arange ( 24 ). reshape ( 2 , 3 , 4 ) print ( t . shape ) # torch.Size([2, 3, 4]) print ( t . transpose ( 0 , 1 ). shape ) # torch.Size([3, 2, 4]) print ( t . transpose ( 1 , 2 ). shape ) # torch.Size([2, 4, 3]) The order of the two arguments doesn't matter — t.transpose(0, 1) and t.transpose(1, 0) are the same thing. A swap is a swap. On a 2-D tensor this is the matrix transpose you already know, and .T is the shorthand: m = torch . arange ( 6 ). reshape ( 2 , 3 ) print ( m . T . shape ) # torch.Size([3, 2]) print ( m . transpose ( 0 , 1 ). shape ) # torch.Size([3, 2]) — identical One caution on .T : on tensors with more than two dimensions, .T reverses every dimension, and modern PyTorch has deprecated that

Learn how to build professional PDF reports in Odoo 19 using QWeb . This guide covers everything from creating your first report to advanced techniques like reusable templates, custom paper formats, barcodes, multilingual reports, RTL support, and performance optimization. Introduction Every Odoo application relies on reports. Whether you're printing: Sales Quotations Customer Invoices Purchase Orders Delivery Slips Manufacturing Orders Inventory Labels Payroll Documents Custom Certificates you're using QWeb , Odoo's XML-based templating engine. Although creating a basic report is straightforward, building maintainable, scalable, and professional reports requires understanding how the entire reporting pipeline works. In this tutorial, we'll build a complete report from scratch while exploring best practices used by experienced Odoo developers. By the end of this guide, you'll be able to: Create custom PDF reports Understand how Odoo generates PDFs Design reusable templates Display relational data Build dynamic tables Format currencies and dates correctly Add company logos, images, barcodes, and QR codes Create custom paper formats Pass additional data from Python Optimize report performance Debug common QWeb issues How Odoo Generates a PDF Before writing any XML, it's important to understand the report generation process. User clicks "Print" │ ▼ ir.actions.report │ ▼ Report Model (_get_report_values) │ ▼ QWeb Template │ ▼ Rendered HTML │ ▼ wkhtmltopdf │ ▼ PDF Download Each step has a specific responsibility: Component Responsibility ir.actions.report Registers the report Report Model Prepares business data QWeb Generates HTML wkhtmltopdf Converts HTML into PDF Understanding this workflow makes debugging significantly easier. Project Structure A clean module structure helps keep reports maintainable. my_module/ │ ├── models/ │ └── sale_order.py │ ├── report/ │ ├── sale_order_report.xml │ ├── report_action.xml │ └── paperformat.xml │ ├── security/ │ ├── views/ │ └── _

hey there, so i wanted to share something with you. this is a bit personal but i have been watching the news this week and bruh... things are not going good. i am jobless right now, no other source of income, and day by day things are getting worse. and the worst part? AI is literally fuking every job in the software field. so when i saw this week's stock market drama, it hit me different. Microsoft popped. Meta tanked. Same AI boom. Two completely opposite reactions. and all i could think was... yeah, this is exactly my life right now. The Numbers, Bruh let me break it down real quick because this is wild: Microsoft jumped like 15% after beating expectations. Azure grew 43%. full year Azure revenue crossed $100 billion. insane. Meta dropped 8–9% after missing on guidance. their free cash flow collapsed 91% year-over-year to just $784 million. like... 91%?? gone. same AI boom. same crazy spending. and the market said "you're amazing" to one and "you're done" to the other. Why Microsoft Won Microsoft actually showed receipts. they didn't just talk about AI, they showed the money coming in. Azure is growing, Copilot is making real revenue, investors can literally see the line between billions spent and billions earned. lesson? Wall Street doesn't hate AI spending. it hates AI spending without proof. Why Meta Lost Meta's problem is that nobody can see where the money comes back. Zuckerberg talked about the "AI capacity dilemma" — how much compute to keep for yourself vs sell to others. but guidance missed, free cash flow went to hell, and the market was like... nah bro, i need answers. and honestly? i relate to that feeling more than i want to admit. putting everything into something and people still saying "not enough." The Bigger Picture this week is a preview of everything coming. companies are dumping hundreds of billions into data centers, chips, and models, all betting AI demand keeps exploding. the ones who can prove it pays off? they get rewarded. the ones who

Two weeks ago, I published "Why Agent Evaluation Is Harder Than Model Evaluation." The core argument:...

So, here's the thing. A few months ago, I kept hearing these four words everywhere — AI, machine learning, deep learning, generative AI — and honestly? I just nodded along like I knew what they meant. I didn't. Not really. Then I actually sat down and learned them properly, and it turns out they're way simpler than people make them sound. So here's my attempt at explaining them the way I wish someone had explained them to me. No scary maths, no fifty-page research papers. Just the actual ideas. First, the one thing everyone gets wrong These four terms are NOT the same thing. They're more like Russian dolls — each one fits inside the bigger one: AI is the biggest doll. The whole concept. Machine learning is inside AI. Deep learning is inside machine learning. Generative AI is a specific use of deep learning. Once I saw it like that, everything else clicked into place. AI: the big umbrella Artificial intelligence is basically any system that does something we'd normally say requires human thinking. That's it. That's the definition. And here's the part that surprised me — AI is old. Like, really old. The chess computer that beat Kasparov in 1997? That's AI. The enemy characters in old video games that chase you around? Technically AI. Most of that stuff doesn't "learn" anything. A programmer just wrote a bunch of rules, like "if the player is close, move towards them." So AI ≠ robots taking over the world. Most AI is honestly pretty boring. It's spam filters, autocorrect, and the thing that recommends which video plays next. Machine Learning: where it gets interesting This is where computers stopped following rules and started finding them. The classic example: a spam filter. The old way, a programmer would write rules like "if the email contains the word FREE!!! in all caps, it's spam." But spammers just change their spelling and the rules break. It's a never-ending game of cat and mouse. Machine learning flips it around. Instead of writing rules, you show the compute

I'm halfway through the MLH Production Engineering Fellowship, and while I've learned a lot technically—from Linux fundamentals, Docker, NGINX, automated testing, and contributing to open source, the thing that has stood out to me most is how well the program is structured. Beyond the technical curriculum, there is a strong emphasis on interview preparation and career growth. We’ve had regular opportunities to practice technical interviews, receive feedback, and stay in close contact with our Meta mentors, who have been incredibly approachable throughout the program. Looking forward to seeing what the second half of the fellowship has in store. Thanks to the MLH team, mentors, and my podmates for making it such a rewarding experience so far!

You've learned not to trust the first answer. So you read it carefully. You spot two problems. You fix them yourself, ship it, and move on. That's a reasonable way to work, and it's what separates an engineer who uses these tools well from one who copies and pastes. But there's a step you skipped. You never asked Claude to find the problems, and asking produces a different kind of output than reviewing does. 🔍 What actually happens Here's a specific case. You ask for an incremental load. You get something clean: a watermark column, a filter on records newer than the last run, an upsert into the target. You review it. You notice it assumes source records arrive in order, which yours don't, so you add a buffer window. You notice it doesn't handle the first run when the watermark is null, so you add a default. Two fixes, maybe fifteen minutes, and now it's correct. What you didn't find was the third problem: the upsert assumes a stable business key, and in your source system that key gets reassigned when records are merged. That one surfaces in production six weeks later as duplicate rows nobody can explain. You caught the problems you were looking for. You didn't catch the one you weren't. This is the normal outcome of self-review. You check against your own mental list of things that go wrong, and your list is good but finite. The problems that hurt are the ones outside it. 🧠 Why intermediates specifically miss this Beginners don't review AI output much at all, so this isn't their failure mode yet. Seniors have usually developed the habit after being caught out by something their own review missed. Intermediates sit in an awkward middle. They have learned, correctly, that AI output needs questioning. And they have concluded, understandably, that the questioning is entirely their job. That conclusion makes sense. Reviewing is what you do with a junior's pull request. It's what you do with your own code before you push. Review is a human activity performed on work some

How a single contiguous allocation — and a type system that won't let you feed strings to a scaler — is the real reason datarust fits in 2.3 megabytes. In the last post I showed you the whole datarust workflow: impute, scale, one-hot, train a logistic regression, evaluate, and save it as JSON — all without a Python runtime in sight. The Docker image shrank from ~900 MB to ~8 MB, and the binary was 2.3 MB. But I skimmed over something important. I kept saying "the flat memory layout" as if it were a detail. It isn't. It's the whole bet. Every scaler, every encoder, every model, every metric in datarust runs on top of one data structure. If you understand that structure — why it looks the way it does and what it refuses to let you do — the rest of the library stops being magic. So let's zoom in. Meet Matrix . Two containers, on purpose Real data is mixed. Numbers in one column, strings in the next. In Python, everything flows through one giant numpy.ndarray or a pandas.DataFrame , and the type system just... shrugs. A string column next to a float column gets coerced into object dtype. You'll find out at training time, in the form of an error message three frames deep. datarust does the opposite. It splits your data into two types at the source: use datarust :: Matrix ; use datarust :: matrix :: StrMatrix ; let numeric = Matrix :: new ( vec! [ vec! [ 3.0 , 85.0 , 24.0 ], vec! [ 12.0 , 70.0 , 31.0 ], vec! [ f64 :: NAN , 95.0 , 45.0 ], ]) ? ; let categorical = StrMatrix :: from_strings ( vec! [ vec! [ "MonthToMonth" ], vec! [ "OneYear" ], vec! [ "MonthToMonth" ], ]) ? ; Matrix is f64 only. StrMatrix is strings only. They are different types , and the compiler will refuse to compile a program that hands a string column to a scaler. Not at runtime — at compile time. In the last post I called this "putting on glasses for the first time." Let me show you what it actually buys you. The ColumnTransformer API is built on that split: ct .add_numeric ( "scaled" , vec! [ 0 , 1 ],

Originally published on tamiz.pro . The prevailing narrative in artificial intelligence has been dominated by cloud-based, API-driven models. While this approach offers scalability, it introduces critical latency, dependency on external services, and significant privacy concerns regarding data exfiltration. For mission-critical applications, financial analysis, or healthcare systems, the inability to guarantee data residency and offline operation is a non-starter. The solution lies in a "Local-First" architecture, where the AI assistant runs entirely on-premise or on-device. However, building such systems requires more than just downloading an LLM weights file; it demands a robust infrastructure layer capable of managing state, memory safety, and real-time concurrency. This article explores how to construct this infrastructure using two powerhouse languages: Go for its superior concurrency primitives and developer velocity in orchestration, and Rust for its memory safety, zero-cost abstractions, and performance-critical inference execution. We will dissect the architecture of a secure, local-first AI agent, moving from the conceptual model to the implementation details, focusing on the boundary between the orchestration layer (Go) and the execution layer (Rust). 1. The Architectural Paradigm: Separation of Concerns Building a local-first AI assistant is not merely a software engineering challenge; it is a systems architecture problem. The core tension lies between flexibility (the ability to swap models, adjust prompts, and handle complex workflows) and performance/security (minimizing latency and preventing memory corruption or data leaks). To resolve this, we adopt a micro-kernel architecture : The Orchestrator (Go): Handles the user interface, API gateway, session management, tool calling, and high-level logic. Go’s goroutines allow it to manage thousands of concurrent agent sessions with minimal memory overhead. The Engine (Rust): Handles the heavy lifting: mode

大模型来了，有个说法是如果一个问题容易验证 那么ai就容易学会解决！说说这个特性与p np问题的关联性 这个说法听起来很直观，但其实 混淆了"验证的复杂性"和"学习/求解的复杂性"这两件不同的事 。我们把它拆开看。 先把"容易验证"在 P/NP 里的精确定位理清 在计算复杂度理论中： NP = 给定候选解（证书），能在多项式时间内验证其正确性的问题 P = 能在多项式时间内直接求解的问题 P ≠ NP ? = 是否所有容易验证的问题，也都容易求解？ 所以"容易验证"在 CS 里的严格含义是： 验证者在多项式时间内工作 ， 不是说 AI 训练成本低 。 "容易验证 ⇒ AI 容易学会"——部分成立，但有重要的限定 这个直觉 在某些场景下确实成立 ，原因是"验证"提供了 稠密的训练信号 ： ✅ 成立的情形：验证器可作奖励/过滤 当一个问题具备"易于验证"的结构时，我们可以用它来： 生成训练数据 ：比如 SAT 问题，随机生成一个赋值，代入公式验证，正确就得到一对 (公式, 赋值) 训练样本—— 数据无限且免费 RL 中的奖励塑形 ：LLM 生成代码 → 编译器/单元测试验证 → immediate reward Self-play / 自我蒸馏 ：AlphaGo 等用模拟器验证落子结果 Verifier-Guided Search ：用"易于验证"的判据引导 beam search / MCTS，如 AlphaCode、AlphaGeometry 💡 这就是为什么像 代码生成、形式化证明、数学解题 这些领域近期进展飞快——它们都有"相对容易的验证器"（单元测试、类型检查器、证明校验器）。 ❌ 但这个推论远非普遍成立 "容易验证"≠"AI 容易学会"，有几个关键原因： 1. 验证器只给二值信号，梯度稀疏 验证器通常只输出 0/1（对/错），而深度学习需要平滑的损失曲面。对于复杂的 NP 问题，绝大多数随机猜测都是错的 → 奖励恒为 0 → 梯度消失，学不到东西 。这就是"稀疏奖励"难题。 2. P ≠ NP 意味着：验证简单 ≠ 求解简单 即使验证是 O(n)，找到那个能通过验证的解可能仍需 O(2ⁿ)。AI 模型本质上是在做启发式搜索，面对组合爆炸， 没有 free lunch 。例如： 数独：验证 O(n²)，但最难的数独对人类和 AI 都极具挑战 TSP：验证一条回路 O(n)，但找最优回路是 NP-Hard 3. 分布偏移与泛化 NP 问题的"容易验证"是** worst-case 复杂度**意义下的。AI 学到的是训练分布的统计规律，遇到分布外的实例会失效。比如 LLM 在数学竞赛题上表现好，但换个数字或换种表述就可能崩。 4. 验证本身也可能不在 NP 里 很多现实问题是 PSPACE 或更难 （如围棋先手胜负），验证一个"策略"需要指数时间——这种问题连"提供证书让 AI 模仿"都很困难。 一张对照表 问题类型 验证复杂度 AI 易学吗？ 例子 P 类 多项式 通常容易 （有高效算法可直接教） 排序、最短路径 NP-Complete，且有稠密验证信号 多项式 中等 （RL + 验证器有效） SAT、数独、TSP 近似 NP-Complete，但验证信号稀疏 多项式 困难 （奖励太稀） 某些密码学难题 超出 NP（PSPACE 等） 超多项式 极难 （验证本身就很贵） 围棋先手胜、QSAT 不可判定 不存在 不可能 （理论上限） 程序等价性 真正的关联在哪里 "容易验证 ⇒ AI 容易学会"更准确的说法应该是： 📌 如果一个问题有"多项式时间的验证器"，并且我们能从中提取稠密的训练信号（如 partial credit、逐步验证），那么 AI 可以通过"生成 + 验证"的循环去逼近求解。 这本质上就是 用 NP 的"验证侧"去攻击"求解侧" ——也是当前 LLM + Verifier 范式（如 RLHF 中的 reward model、AlphaProof 的 formal verifier）的理论基础。 但要注意： 这不是 P=NP 的证明，AI 找到的解在 worst-case 仍可能不是最优的 AI 解决的是 平均情况（average-case） 或 特定分布 ，而非 worst-case 一旦问题规模增大到超出训练分布，性能会急剧下降 一个更深的视角：平均-case 复杂度 理论计算机科学里有个分支叫 Average-Case Complexity ，研究"典型实例"的难度。很多 NP-Complete 问题在 average-case 下其实有不错启发式算法——这也解释了为什么 AI 在某些 NP 问题上表现惊喜，但在 adversarial 构造的 hard instance 上翻车。 所以回到你的说法： "

Yesterday I announced I'm blogging daily on AWS & DevOps. Here's Day 1 — the fundamentals everything else builds on. ## What is Cloud Computing? Instead of setting up and maintaining infrastructure on-premises, you now access computing resources remotely over the internet — this is Cloud Computing. "Cloud" refers to a network that provides resources over the internet, accessible whenever needed. It evolved from grid computing, virtualization, and distributed computing. All you need to use it is a web browser. As per NIST , cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (networks, servers, storage, applications, services) that can be rapidly provisioned and released with minimal management effort. Key characteristics: uses virtualization, enables on-demand access, and offers "pay-as-you-use" pricing. Traditional companies had to spend heavily on infrastructure, hardware, and operations. With cloud computing, providers manage all of this — handling troubleshooting, recording activity, and sending analytics data to users. Service Models — IaaS, PaaS, SaaS IaaS : Providers offer databases, servers, storage, and networking as a service, and you pay per use. Examples: AWS, Azure, GCP. PaaS : Gives you an on-demand environment for developing, testing, and delivering apps, with ready dev tools already set up. Examples: Heroku, Google App Engine. SaaS : Delivers ready-to-use software over the internet, usually via subscription, with the provider managing everything underneath. - Examples: Gmail, Microsoft 365, Google Drive. The layered view: moving from On-Premise to IaaS to PaaS to SaaS, each model hands you a bigger pre-managed slice. On-premise means you manage everything yourself. IaaS shifts virtualization, servers, storage, and networking to the vendor. PaaS additionally hands over OS, middleware, and runtime. SaaS means the vendor manages everything — you just use the app. The biryani a

Please post your personal projects, startups, product placements, collaboration needs, blogs etc. Please mention the payment and pricing requirements for products and services. Please do not post link shorteners, link aggregator websites , or auto-subscribe links. -- Any abuse of trust will lead to bans. Encourage others who create new posts for questions to post here instead! Thread will stay alive until next one so keep posting after the date in the title. -- Meta: This is an experiment. If the community doesnt like this, we will cancel it. This is to encourage those in the community to promote their work by not spamming the main threads. submitted by /u/AutoModerator [link] [留言]

A message landed in my inbox a few months back. New scope, same title. Frontend, backend, and QA, folded into one role, because the team now had AI to cover the rest. I had shipped backend work for years. The frontend half of our codebase, and the QA half, I had barely touched. Reading someone else's frontend patterns for the first time, at speed, with a deadline attached, is its own skill and I did not have it yet. I said yes anyway. Has your role quietly grown a second and third job inside it Not a promotion. Not new headcount. The same title, the same paycheck window, and suddenly three disciplines expected of one person because a tool now sits in the gap where two teammates used to be. I want to be honest about what that gap actually feels like from the inside, because most of what I read about this treats it as a spreadsheet problem. It is not. It is a specific, physical kind of tired that shows up on a Tuesday when you are debugging a CSS layout you have no instinct for, at 6pm, after a full day of the work you actually trained for. The tool covers the syntax, not the judgment AI got me through the mechanical parts fast. Flexbox, a broken build step, the shape of a test file I had never written by hand. Genuinely fast. I could paste an error and get a plausible fix in under a minute. What it never gave me was the judgment for when the plausible fix was wrong for THIS codebase, and why this component was structured the odd way it was. Whether a generated test actually proved anything, or only made the red X turn green. That judgment only comes from having broken things in that specific layer before, and I had never broken anything in QA before, so I had none. The tool closes the syntax gap instantly. It does nothing for the judgment gap. Those are different gaps, and conflating them is where I think a lot of the current AI-productivity optimism goes wrong. What actually closed it, and what did not Reading transcripts of AI-assisted changes other people made in

While struggling to understand channels in go, I would try out many things in my sandbox repository. I encountered deadlock errors and stuff about go routes being asleep. I came to understand that the order of execution played a role and that with unbuffered channels you need a sender and a receiver ready at the same time (kind of). I wrote a short article on my blog site about the experience The Unbuffered Channels In Go Lesson I Think Has Finally Clicked for Me 🤷🏽‍♂️

Originally published on tamiz.pro . The initial euphoria surrounding Large Language Models (LLMs) was largely driven by their ability to generate code. We saw demos of developers asking an LLM to write a React component, a Python data pipeline, or a SQL query, and watching it appear instantly. This capability, while impressive, is fundamentally different from the engineering challenges posed by AI Agents. A code generator is a stateless tool; an AI Agent is a stateful, autonomous entity that interacts with external systems, makes decisions, and executes actions over time. Treating an AI Agent like a code generator is the primary reason most AI projects fail to reach production. When you move from generating static artifacts to orchestrating dynamic, multi-step workflows, the complexity shifts from syntax correctness to systemic reliability. In this deep dive, we explore why production-grade AI Agents require a paradigm shift in engineering, focusing on three critical pillars: rigorous state management, comprehensive observability, and deterministic control flows. The Fundamental Shift: Stateless Generation vs. Stateful Execution To understand the engineering gap, we must first distinguish between what a code generator does and what an agent does. A Code Generator operates in a Request -> Response loop. The input is a prompt; the output is a snippet of code. The LLM does not retain memory between calls, does not modify external state (like a database), and does not decide its own next steps based on runtime errors. It is a function with high entropy. An AI Agent is a loop. It observes the environment, reasons about the next best action, executes that action (often via tools or APIs), and observes the result. This creates a feedback loop: Observe -> Think -> Act -> Observe -> Think -> ... This loop introduces several engineering complexities that static code generation does not: Non-Determinism: The agent’s path through the workflow is not fixed. It depends on the LLM

The pitch sells itself. An assistant that's entirely mine, running on my own machine, needing no connection, with nothing I type ever leaving the room. No company counting my tokens. No subscription. No outage on someone else's servers wrecking my afternoon (I'm looking at you, Anthropic, and your recurring outages). I wanted that badly enough that I spent a few months chasing it, and I want to tell you honestly where it left me. 24GB sounds like plenty until you load a model My Mac has 24GB of memory. This felt generous when I bought it, but then you load a real language model and that number shrinks fast. The system keeps its cut because the computer needs to keep running, and what's left for the model is closer to two-thirds of the sticker figure. The models actually worth trusting sit right at that ceiling or just past it. So you have to choose: a model that fits comfortably and isn't very bright, or a smarter one that leaves the machine gasping. The obvious fix is more memory, but have you seen memory prices lately? The timing could not be worse. Memory got expensive in a way that still surprises people who haven't shopped for it in a while. DRAM has roughly doubled in price since the start of 2025, and the analysts who watch this space think it could climb another 70% or so across 2026. Storage is worse in spots. The raw NAND wafers that SSDs are cut from are trading at something like eight times where they sat in the middle of last year, and a 4TB drive I'd have paid about $250 for not long ago now wants north of $700 — and because the market is so volatile right now, when this blog post goes live these numbers might be totally different because it's 2026 and who knows how much RAM and SSDs will cost. The reason for this insanity is also the reason behind half the stories in tech right now — AI. The big datacenter buildouts are on track to swallow around 70% of the world's high-end memory this year, and the cloud giants have signed contracts that lock up prod