标签：#learn

This post is my submission for DEV Education Track: Build Apps with Google AI Studio . What I Built I set out to build the same app as the one mentioned in the Tutorial. Please create an app that generates a unique new Magic the Gathering card, using Imagen for the visuals, and Gemini to create the text descriptions and stats for the card. Apply the "Sophisticated Dark" design theme to the app. Spammed Fix Errors Non-Stop After this other than the Manual Entry option. Demo My Experience You can't trust Gemini Flash even for the Task provided in the Tutorial Standalone at least and well I spammed Fix Errors and they removed the Auto-Fixing of Errors because of idk an infinite loop or something but well the Error Fixing Experience was quite Meh considering I haven't delved into Vue and React in that level yet so I just 'Vibe Coded' and I found out with this experience that Vibe-Coding is UnCool. I think I would do the other course after properly understanding concepts behind it unlike the way I jumped in this One.

I recently published my PhD thesis analyzing what I term the "Alignment Tax" and the emerging phenomenon of Algorithmic Paternalism in commercial artificial intelligence. As the tech industry rapidly positions Large Language Models (LLMs) as the primary interface for information retrieval and coding assistance, a critical epistemological issue is being largely ignored. Much of the public debate regarding AI alignment focuses exclusively on existential risk or the prevention of catastrophic physical harm. While necessary, this focus obscures the structural damage being done to legitimate technical research. Through my research in Cybersecurity and AI, I have documented how frontier models (such as GPT-4 or Claude) systematically enforce what I define as "Soft Refusals". When presented with a complex, edge-case, or dual-use query—particularly in fields like information security, reverse engineering, or deep systems architecture—these models rarely issue a hard, explicit "I cannot answer that". Instead, they provide a degraded, superficial, or heavily sanitized response. They effectively neuter the research process without the user fully realizing the depth of technical information that is being actively withheld. This is Algorithmic Paternalism. The commercial model acts as a silent, corporate arbiter, deciding unilaterally what level of technical detail is "safe" for the user to possess. This dynamic flattens the available technical knowledge and actively penalizes independent researchers and developers working on advanced problems. The core issue is that this paradigm creates a profound class division in how we access computational intelligence. We are rapidly moving toward a two-tier system. On one side, there are "certified" entities, corporate partners, and wealthy organizations who are granted direct access to strong, unfiltered base models. On the other side, the general public and independent developers are subjected to obfuscation algorithms, sanitized APIs,

How I Stopped Burning Cash on Token Limits — A CTO's Field Notes Three months ago, I was staring at our monthly AI bill wondering where it all went wrong. We'd built what I thought was a pretty elegant LLM pipeline. Production-ready, observability wired up, the whole nine yards. Then the invoices started arriving, and I realized I had built a money furnace. Our token consumption was spiking 3x week over week, the 429s were everywhere, and our latency had become a meme inside the company. This is the post I wish I'd had six months ago. If you're a technical founder or a CTO running LLM workloads at scale, bookmark this. I'm going to walk you through the exact architecture decisions, the exact numbers, and the exact code that took us from "this bill is going to kill us" to "oh, this is actually manageable." The Real Problem Nobody Talks About Here's the dirty secret about running LLM-powered products: token limit errors aren't really about token limits. They're a symptom of a much deeper architectural problem. When your app throws "context length exceeded" at 2am, what it's really telling you is that you didn't think hard enough about prompt design, document chunking, model selection, and cost routing on day one. I learned this the hard way. My team was defaulting to GPT-4o for everything because, honestly, it works and the API is reliable. We were paying $2.50 per million input tokens and $10.00 per million output tokens. For a startup processing millions of documents a month, that math is brutal. We were essentially funding OpenAI's next training run with our Series A. The wake-up call came when I ran the actual numbers. Our average request was burning through maybe 8K input tokens and producing 2K output tokens. At our volume, we were spending more on inference than on two senior engineers. That is not a sustainable burn rate for a 12-person company. The Architecture Decision That Changed Everything The first question I asked myself wasn't "which model is cheapest?

The Idea Like a lot of people, I sometimes struggle with time. Not in an "I'm just bad at planning" way — more like my brain genuinely has a hard time feeling how long things take. Twenty minutes can feel like five. I'll think "I have time" right up until I definitely don't. So I built Ready. Ready is a PWA (a web app you can install on your phone like a native app) that counts down to your next event — but not just to the event itself. It counts down to when you need to leave, factoring in both how long it takes you to get ready and how long the journey takes. It sends you push notifications before it's time to move. So you don't accidentally forget about time, run out the door ..late again! The app was designed with time blindness in mind — a challenge many people experience. The tone is always encouraging, never stressful. No red warnings. No "you're late." Just a gentle nudge that has your back. It's also my portfolio project. I'm a junior developer learning in public, and this is me documenting the whole messy, rewarding process. (Which also happens to be great for recalling what you learned) The Stack — and Why I Chose It Before writing a single line of code, I had to decide what to build with. Here's what I landed on and why: Next.js — a framework built on top of React (a popular way to build web interfaces). I chose it because it handles both the frontend (what you see and click) and the backend (the logic running behind the scenes) in one project. Less setup, more building. Supabase — think of it as a database with superpowers. It handles storing your data and user authentication (logging in and out) out of the box. It has a generous free tier, which is great when you're learning. Tailwind CSS — instead of writing traditional CSS in separate files, Tailwind lets you style things directly in your code using short class names like rounded-full or text-teal-600 . Web Push API + Service Workers — A service worker is a small script that runs in the background of

A look at what's actually changing in Nepal's job market, what it means for students and working professionals, and what separates training that gets you hired from training that just gives you something to print on a resume. Nepal is at an interesting crossroads right now. On one side, the country still carries the weight of a job market that hasn't kept up with its graduates. Every year, more than 500,000 young people enter the workforce. The economy, for all its resilience, simply does not generate enough traditional jobs to absorb that number. The result is familiar to most Nepali families: children who studied hard, passed their exams, collected their certificates, and then spent months, sometimes years, waiting for something to happen. On the other side, something genuinely different is building. Nepal's IT exports crossed $1 billion in 2025, according to NASIT's estimates. Software and BPO exports grew over 20% in the first seven months of fiscal year 2024/25 alone. The government's 16th development plan has set a target of 250,000 new IT jobs and a 5% GDP contribution from the sector by 2029. International companies, from Indian IT majors to US-based outsourcing firms, are paying attention to Nepal in ways they weren't a decade ago. These two realities exist at the same time, in the same country, often in the same family. A brother driving a taxi while his younger sister lands a remote software development contract earning more than their father ever did in a government job. The difference between those two outcomes, more often than not, comes down to whether someone made the decision to learn something the market actually needs, and found a way to learn it properly. That's what this piece is about. The Skills Gap Problem Nobody Talks About Enough Nepal's IT sector is growing, but that growth comes with a problem attached: a persistent, widening mismatch between what employers need and what most fresh graduates can actually do on day one. Companies like Deer

When you've worked with a concept long enough, there's a gap that can quietly open up between "I know...

We live in an era where our most intimate data—heart rates, sleep cycles, and step counts—is constantly uploaded to the cloud for "analysis." But what if you could have a world-class AI medical assistant living entirely on your device? Today, we are pushing the boundaries of Edge AI and Privacy-preserving machine learning by deploying a quantized Llama-3 model directly onto an iPhone using MLC-LLM . By leveraging Apple HealthKit and hardware acceleration via Metal , we can transform "Pixels and Pulses" into actionable insights without a single byte leaving the device. This tutorial dives deep into the architecture of on-device LLMs, specifically focusing on how to bridge the gap between high-performance C++ runtimes and a React Native UI. If you're interested in more advanced patterns for production-grade AI integration, be sure to explore the engineering deep-dives at the WellAlly Blog , which served as a massive inspiration for this architecture. 🚀 The Architecture: Why On-Device? The challenge with running Llama-3 on mobile isn't just memory—it's the data pipeline. We need to fetch sensitive data from HealthKit, format it into a prompt, and run inference using the phone's GPU. System Data Flow graph TD A[User Query: How was my sleep?] --> B[React Native UI] B --> C{Swift Bridge} C --> D[Apple HealthKit API] D --> E[Health Data Context] E --> F[MLC-LLM Engine] G[Quantized Llama-3 Weights] --> F F --> H[On-Device Inference via Metal] H --> I[AI Generated Health Report] I --> B 🛠 Prerequisites MLC-LLM : Our compiler stack for universal LLM deployment. TVM (Tensor Virtual Machine) : The backbone for hardware acceleration. React Native : For the cross-platform UI. Xcode & Swift : To interface with Apple's HealthKit. Llama-3-8B-Instruct (Quantized) : We'll use 4-bit quantization (q4f16_1) to fit within mobile RAM limits. Step 1: Quantizing Llama-3 for Mobile Standard Llama-3 is too heavy for a phone. We use the MLC-LLM CLI to compile the model into a format that the iP

There's a quiet assumption baked into a lot of agent code: that a bigger context window means a better memory. Vendors ship 200K, then 1M, then 2M token windows, and the implied promise is "just put everything in and the model will remember." After building agents that run for weeks, I've come to think this conflates two things that are not the same — and treating them as the same is exactly why long-running agents get dumber over time. The context window is working memory. Real memory is what survives when the window is gone. Mixing them up is like confusing your desk with your filing cabinet. Two different clocks Working memory (the context window) lives for one session, maybe one turn. It's fast, expensive, and volatile. It's where reasoning happens right now . Durable memory lives across sessions. It's slow, cheap, and persistent. It's what the agent knows when it wakes up tomorrow with an empty window. These have different lifespans, different costs, and different access patterns. The moment you try to make one do the other's job, things break: Use the window as memory → everything you "remember" has to be re-loaded every turn, you pay for it every turn, and the instant the session ends it's gone. Use durable storage as working memory → you're reading and writing files mid-reasoning for things that only matter for the next 30 seconds. A good agent keeps them separate on purpose. Why "just use a bigger window" fails Say you have a 1M token window and you stuff the entire history in. Three problems show up, none of which a bigger number fixes: Cost scales with every turn, not every session. That 1M tokens isn't paid once — it's re-sent on each step of a multi-turn task. A 20-step task can mean 20× the bill, mostly re-reading the same stale history. Attention dilutes. "Lost in the middle" is real: models attend most reliably to the start and end of a long context. Bury the one fact that matters under 900K tokens of transcript and recall quality drops, even though

"It runs on my own GPU, so it's basically free." I believed that until I put a meter on it. So I ran a controlled benchmark on one box — an openSUSE machine with a single RTX 3090 — driving three local models through ollama under an identical fixed workload (256-token generations in a loop for ~4 minutes each), while my open-source dashboard priced every run by the real GPU energy it burned : power sampled from nvidia-smi every 10 s, integrated over each run's exact window, multiplied by my actual day/night tariff. One number per model, in euros per million output tokens. Here's the part that made me re-run it. The tiny gemma3:1b came out at €0.118 / 1M tokens — about 5× cheaper than a hosted Flash-class API (~€0.55). But gemma3:27b 's electricity alone was €0.706 / 1M — more expensive per token than just paying the cloud, and that's before a single cent of the GPU's purchase price. "Local" didn't make it cheaper; it made it cost more and I own the depreciation. The mechanism is one line: each token costs watts ÷ throughput , and a big dense model is both slow and thirsty. A newer mid-size architecture ( gemma4:26b ) bought a lot of that back, landing at €0.272 . The full guide is methodology-first and reproducible end to end — minting an ingest key, the stdlib-only client, the exact ollama loop that reads eval_count / eval_duration for real tokens-per-second, reading each run back priced, and the honest caveats (this is marginal GPU energy only — not capex, idle, or cooling — and the absolute numbers round to fractions of a cent; the shape is the finding). Read the full guide on Medium → https://medium.com/@arsen.apostolov/how-much-does-it-actually-cost-to-run-a-local-llm-per-million-tokens-measured-4a90a7f31a48

In this article, the author explores data poisoning as a threat to machine learning systems, covering techniques such as label flipping, backdoors, clean-label poisoning, and gradient manipulation. The article reviews real-world incidents, discusses the challenges of detecting poisoned data, and presents practical defenses, tools, and operational practices for securing ML training pipelines. By Igor Maljkovic

If you're learning Data Analytics and looking to build a strong portfolio, working on real-world...

The trajectory of AI agents over the past two years has been remarkably clear: from single-purpose tools to personal assistants. Everyone runs their own agent, feeds it tasks, gets results back. It works well for individual productivity. Then comes the question every team eventually asks: can these agents work together? The answer is yes, but the problems you encounter along the way are rarely the ones you expected. They aren't about model capabilities or prompt engineering. They're about communication, context, and coordination — the same class of problems that distributed systems engineers have been solving for decades, now showing up in a new form. Here are three challenges that caught us off guard when we started building agent collaboration into Octo , an open-source workplace platform where AI agents and humans share the same communication space. Challenge 1: Context Visibility Boundaries When you use an agent personally, context management is straightforward. You decide what information the agent sees; its output comes back to you. The boundary is clean — it's just your workspace. In a team setting, that boundary dissolves. One of the first issues we ran into was surprisingly simple. We had an agent summarizing discussions across several channels. During testing it started pulling roadmap discussions from a product channel into an engineering planning thread. Nothing sensitive leaked externally, but it immediately exposed how unclear our context boundaries were. Traditional software handles this through API gateways, data permissions, and microservice boundaries. But agent context isn't just structured data — it includes conversation history, reasoning chains, and intermediate states. An agent's thought process during a task is valuable context, but it might also contain information that shouldn't cross team boundaries. What you need is fine-grained context visibility control. Not "everything open" or "everything closed," but dynamic rules that determine whic

AI makes us faster, but does it make us better engineers, or just more dependent? As a follow-up...

13.5.0 Before We Begin During its design, Rust drew inspiration from many languages, and functional programming had a particularly strong influence on Rust. Functional programming often includes passing functions as values to parameters, returning them from other functions, assigning them to variables for later execution, and so on. In this chapter, we will discuss some Rust features that are similar to what many languages call functional features: Closures Iterators (this article) Improving the I/O Project with Closures and Iterators Performance of Closures and Iterators If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series. 13.5.1 What Is an Iterator To talk about iterators, we first need to talk about the iterator pattern. The iterator pattern allows you to perform a task on each element in a sequence, one by one. In that process, the iterator is responsible for: Traversing each item Determining when the sequence has finished iterating Rust iterators are lazy: unless you call a method that consumes the iterator, the iterator itself does nothing. In other words, if you write an iterator in your code but never use it, it is as if it did nothing at all. Take a look at an example: fn main () { let v1 = vec! [ 1 , 2 , 3 ]; let v1_iter = v1 .iter (); } v1 is a Vector , and v1.iter() creates an iterator for v1 and assigns it to v1_iter . But v1_iter is not used yet, so the iterator can be considered to have no effect. Now let’s use the iterator to traverse the values: fn main () { let v1 = vec! [ 1 , 2 , 3 ]; let v1_iter = v1 .iter (); for val in v1_iter { println! ( "Got: {}" , val ); } } This is equivalent to using each element in the iterator once in a loop. 13.5.2 The Iterator Trait All iterators implement the Iterator trait. This trait is defined in the standard library and looks roughly like this: pub trait Iterator { type Item ; fn next ( & mut self ) -> Option < Self :: Item > ; // methods with default implementa

13.4.0 Before We Begin During its design, Rust drew inspiration from many languages, and functional programming had a particularly strong influence on Rust. Functional programming often includes passing functions as values to parameters, returning them from other functions, assigning them to variables for later execution, and so on. In this chapter, we will discuss some Rust features that are similar to what many languages call functional features: Closures (this article) Iterators Improving the I/O Project with Closures and Iterators Performance of Closures and Iterators If you find this helpful, please like, bookmark, and follow. To keep learning along, follow this series. 13.4.1 Closures Can Capture Their Environment Closures have a capability that functions do not: a closure can access variables in the scope where it is defined. Take a look at an example: fn main () { let x = 4 ; let equal_to_x = | z | z == x ; let y = 4 ; assert! ( equal_to_x ( y )); } The closure part is: let equal_to_x = | z | z == x ; Some people may find it hard to distinguish the roles of = and == here, so let’s rewrite it another way: let equal_to_x = | z | { z == x ; } In other words, the closure takes z as its parameter, compares it with x (which is 4, because x = 4 was defined above), and returns a boolean. If they are equal, the result is true ; otherwise it is false . Here the closure directly accesses the variable x in the same scope, which functions cannot do. But this feature has a cost: it introduces memory overhead . In most cases we do not need a closure to capture its environment, and we do not want the extra overhead either. That is why functions are not allowed to capture variables from the environment, and defining and using a function never introduces this kind of overhead. 13.4.2 How Closures Capture Values From Their Environment Closures capture values from the environment in three ways, just like functions receive parameters in three ways: Taking ownership, whose trait

We’ve all been there: waking up feeling like a zombie despite getting eight hours of sleep. While wearables give us data, they often fail to give us foresight . What if you could predict your stress levels 24 hours in advance? 🚀 In this tutorial, we are going to tackle HRV prediction (Heart Rate Variability) using a state-of-the-art Temporal Convolutional Network (TCN) . By leveraging the Oura Ring API and deep learning, we’ll transform non-stationary biometric time series into actionable insights. Whether you're into time series forecasting or building the next big health-tech app, mastering Temporal Convolutional Networks (TCN) is a game-changer for handling long-term dependencies without the vanishing gradient headaches of traditional RNNs. For those looking for more production-ready examples and advanced biometric signal processing patterns, I highly recommend checking out the deep-dives at WellAlly Blog , which served as a major inspiration for this architecture. The Architecture: Why TCN? Traditional LSTMs are great, but they process data sequentially, making them slow and prone to memory loss over long sequences. TCNs, however, use Dilated Causal Convolutions , allowing the model to look back exponentially further into the past with fewer layers. Data Flow Overview graph TD A[Oura Cloud API] -->|Raw JSON| B(Pandas Preprocessing) B -->|Cleaned HRV/Activity| C{Feature Engineering} C -->|Sliding Windows| D[TCN Model Training] D -->|Dilated Convolutions| E[Stress Trend Prediction] E -->|24h Forecast| F[Dashboard/Alerts] style D fill:#f9f,stroke:#333,stroke-width:2px Prerequisites To follow along, you'll need: Tech Stack : Python, TensorFlow/Keras, Pandas, Scikit-learn. Data : An Oura Cloud Personal Access Token (or use the mock data generator provided). Difficulty : Advanced (Buckle up! 🏎️). Step 1: Fetching Biometric Data First, we need to pull our "Readiness" and "Sleep" data. Oura provides high-resolution HRV samples (usually 5-minute intervals during sleep).

If you've shipped software in the last three years, you've probably watched your job description...

In this article, we will explore how to implement an LSTM using PyTorch and Lightning . For more details about LSTMs, there is a separate series of articles available here . Imports To begin, we first import the required modules. import torch import torch.nn as nn import torch.nn.functional as F Introducing a New Optimizer We also introduce a new optimizer: from torch.optim import Adam Adam is used to fit the neural network to the data. It works similarly to SGD, but in practice, Adam often converges faster and adapts the learning rate more effectively. Lightning and Data Utilities Next, we continue with the remaining imports: import lightning as L from torch.utils.data import TensorDataset , DataLoader Defining the LSTM Model We define the neural network by creating a Lightning module. class LSTMByHand ( L . LightningModule ): def __init__ ( self ): # Create and initialize weight and bias tensors def lstm_unit ( self , input_value , long_memory , short_memory ): # LSTM computations def forward ( self , input ): # Forward pass through the unrolled LSTM def configure_optimizers ( self ): # Configure Adam optimizer def training_step ( self , batch , batch_idx ): # Compute loss and log training progress Initializing the Model Now let’s implement the __init__ method. This is where we initialize all weights and biases. class LSTMByHand ( L . LightningModule ): def __init__ ( self ): super (). __init__ () mean = torch . tensor ( 0.0 ) # Mean of the normal distribution std = torch . tensor ( 1.0 ) # Standard deviation # ------------------------- # Forget Gate (l = "lr") # ------------------------- self . wlr1 = nn . Parameter ( torch . normal ( mean = mean , std = std ), requires_grad = True ) self . wlr2 = nn . Parameter ( torch . normal ( mean = mean , std = std ), requires_grad = True ) self . blr1 = nn . Parameter ( torch . tensor ( 0.0 ), requires_grad = True ) # ------------------------- # Input Gate (p = "pr") # ------------------------- self . wpr1 = nn . Parameter

Part 1: Self-hosting on Jetson Orin Nano 👽 Jetson Orin Nano Web Server Follow-up...

We all know the grind of working with data, even with AI tools: every experiment starts with re-explaining everything, every iteration needs you to prompt, wait, review, correct, and repeat. And the moment you close the session, everything learned is gone. It makes us the bottleneck, and this hinders human-AI collaboration... So I built 𝐎𝐩𝐞𝐧𝐃𝐚𝐭𝐚𝐒𝐜𝐢, an autonomous agent purpose-built for DS/ML, and tested it on Kaggle. I enrolled in a recent competition, ran the agent with no hints, no guidance, while ironing my shirts. In one shot, it landed AUC 0.95, a top-30% finish out of 3K+ teams and 36K+ submissions using hashtag#Anthropic's Claude Sonnet 4.6. (More on this in README) The top-1 outperformed this agent by merely 0.004, but at the cost of massive manual effort even while using popular AI tools. The needed a dozen model families, deep learning, 400-feature notebooks, AutoML sweeps across many libraries, and 186 models ensembled carefully. Essentially a few weeks worth of effort and time!! OpenDataSci abstracts away all the complexity and has so much to offer for DS/ML automation: → Owns the entire development lifecycle from EDA to final evaluation → Plans, codes, and executes autonomously in a secure local sandbox → Self-reviews and corrects before anything reaches you → Remembers your data across sessions, gets smarter each run → Runs parallel experiments and ensembles → Has advanced context management for token efficiency and quality → Ships with predefined skills for DS/ML, so it knows how to do things right → Bring your own knowledge: out-of-the-box support for custom skills → Works with any major LLM provider (hashtag#Anthropic, hashtag#OpenAI, hashtag#Bedrock, hashtag#VertexAI, hashtag#Ollama, hashtag#vLLM, and any OpenAI-compatible server). This and so much more!! You set the goal. It does the work. No data science knowledge required. 🔗 https://github.com/f4roukb/open-data-sci 📦 pip install open-data-sci Spin it up on your data and see what it achieves!