DEV Community: KingUSD

WTF is Jev?

KingUSD — Fri, 18 Sep 2026 12:16:45 +0000

Meet Jev, a new AI decision model by TypeSafe AI that drops text generation entirely for millisecond-speed, typed, and structured choices.

The biggest bottleneck in building AI agents today isn't reasoning—it’s latency and structured parsing.

When you want an LLM to act as a router or a code guardrail, you have to prompt it with 50 lines of instructions, beg it to “only return JSON,” and then wait 2 to 4 seconds for it to stream back code. If a single brace is out of place, your application crashes.

A new AI model called Jev (released by TypeSafe AI) completely flips this script.

Jev is a "System One" AI model. It doesn't generate conversational text. It doesn't talk to humans. Instead, it processes data and outputs structured, typed probabilities and choices directly to code in 70 to 500 milliseconds.

What is a "System One" Model?

In psychology, System 1 refers to brain processes that are fast, automatic, and subconscious (like catching a falling ball). System 2 covers slow, deliberate, and logical thinking (like solving a math problem).

While reasoning models like OpenAI's o1 or Anthropic's Claude Sonnet focus on System 2 thinking, Jev is pure System 1.

Built by a team led by former OpenAI researcher Diogo Almeida, Jev uses a custom training method called Reinforcement Learning for Calibrated Decisions (RLCD). Instead of predicting the next text token, it evaluates an input against rigid questions and outputs precise data points.

The Numbers That Matter:

Latency: 70ms – 500ms
Input Price: \$0.042 per 1M tokens (insanely cheap)
Output Price: Free (since it doesn't generate token strings)
Context Window: 32K tokens

How It Works: The 3 Output Types

Instead of prompting Jev with paragraphs, you pass it a global state (can be raw text, user logs, or JSON strings) and ask it narrow, strongly-typed questions. It answers using three exact primitives:

Choice: Pick exactly one item from a pre-defined string array.
Score: Rate an input against an ordered scale (e.g., low, medium, high).
Noul (Boolean Probability): Returns a 0 to 1 float score representing a Yes/No probability.

Because these questions are processed concurrently by the architecture, asking 1 question takes the exact same amount of time as asking 10.

Code Example: Building a Fast Guardrail Middleware

Let’s see how this looks in production. Imagine you are building an AI agent platform, and you want to use Jev as an instantaneous router and safety gateway before letting a user query an expensive LLM.

Here is how you handle it natively in Node.js:

import fetch from 'node-fetch';

async function routeIncomingPrompt(userPrompt) {
  const response = await fetch("https://typesafe.ai", {
    method: "POST",
    headers: {
      "Authorization": `Bearer ${process.env.TYPESAFE_API_KEY}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({
      model: "jev-latest",
      state: `User Input: ${userPrompt}`,
      questions: {
        is_injection_attack: { type: "noul" },
        complexity: { type: "score", scale: ["simple", "intermediate", "complex"] },
        domain: { type: "choice", options: ["coding", "creative", "data_analysis"] }
      }
    })
  });

  const data = await response.json();
  const answers = data.answers;

  // 1. Instant Safety Check
  if (answers.is_injection_attack.noul > 0.85) {
    throw new Error("Security Alert: Prompt injection blocked.");
  }

  // 2. Ultra-Fast Routing Logic
  if (answers.complexity.choice === "simple") {
    return "Route to cheap/fast model (e.g., GPT-4o-mini)";
  } else {
    return "Route to deep reasoning model (e.g., Claude 3.5 Sonnet)";
  }
}

The Python Ecosystem

If you are inside the Python stack, LangChain natively supports Jev through the langchain-typesafe library using their TypeSafeClassifier abstraction, making it easy to drop into existing chains.

Where Jev Wins (and Where It Fails)

Jev isn't a replacement for your core LLMs. It's a completely new layer in the AI stack.

🟢 Perfect For:

Model Routing: Deciding on the fly which model is smart enough for a task.
AI Guardrails: Instantly checking inputs or outputs for safety violations.
Triage & Classification: Tagging customer support tickets or parsing log errors on the fly.
Intent Detection: Replacing heavy semantic-search vector pipelines for simple intent classification.

🔴 Do Not Use For:

Writing copy or summarizing articles.
Complex code generation.
Contextual conversation.

Conclusion

Jev represents a shift away from the "everything is a chatbot" mentality. By turning AI into deterministic, lightning-fast microservices, we can build agents that react instantly without burning through cash or forcing users to stare at loading spinners.

Are you building with Jev yet? What are your thoughts on shifting toward specialized "System One" models rather than all-in-one text generators? Let me know in the comments below!

Building an Interactive Excel Dashboard for E-commerce Product Analysis: A Case Study of Jumia Products

KingUSD — Fri, 11 Sep 2026 02:35:02 +0000

Introduction

Data analysis is not just about creating charts; it is about turning raw and imperfect data into useful business insights. This project focuses on building an interactive Excel dashboard to analyze Jumia product data and understand product performance. Because the dataset contained issues such as missing values, inconsistent formatting, and data quality errors, the first step was to clean and organize the information before any analysis could be done. Since sales data was not available, review counts were used as a proxy for customer engagement. This project shows how careful data preparation, categorization, and visualization can help support better decision-making in an e-commerce setting.

Data Quality Audit and Cleaing

Before any useful analysis could begin, the dataset had to be checked carefully for errors and inconsistencies. The raw data contained issues such as missing values, negative review counts, and duplicate entries, all of which could affect the accuracy of the results. To avoid misleading conclusions, the cleaning process focused on preserving data integrity rather than simply making the dataset look tidy.

One important correction was the handling of negative review counts. Since these were not meaningful values in the context of customer engagement, they were converted into positive numbers. Missing values were also treated carefully, because replacing them with zeros could have incorrectly reduced averages and distorted the analysis. In some cases, data such as price ranges was converted into a single usable value by using the midpoint, which allowed the information to remain part of the dataset without losing its meaning.

Duplicate rows were also removed when they represented repeated records, but similar product names with different prices were kept if they appeared to be separate listings. This careful approach ensured that the cleaned dataset was reliable and suitable for further analysis. In short, the data cleaning step was essential because accurate insights depend on accurate input.

Data Enrichment and categorization

After the data was cleaned, the next step was to enrich it by creating new fields that made the dataset more useful for analysis. Raw numbers can be difficult to interpret on their own, so adding categories and calculated values helped turn the data into something more meaningful and easier to compare.

Several useful transformations were made during this stage. Discount values and discount percentages were calculated to give a clearer picture of how much each product was actually reduced. Products were also grouped into categories such as low, medium, and high price levels, as well as poor, average, and excellent rating levels. Since review count was being used as a proxy for customer engagement, products with high review activity were identified separately to show which items appeared to attract more attention. In addition, flags were created for missing ratings or reviews so that incomplete data could be identified easily during analysis.

This enrichment step improved the quality of the analysis because it made the data easier to interpret and compare. Instead of only looking at individual numbers, the project could now reveal broader patterns and trends across product groups.

Analysis and Key Findings

After the data had been cleaned and enriched, the next stage was to analyze it and look for meaningful relationships. The main purpose of this step was to understand whether factors such as discount levels or product prices had any clear effect on customer engagement and ratings. PivotTables and correlation analysis were used to compare the variables and identify possible patterns.

The results showed that some common assumptions were not supported by the data. For example, higher discounts did not strongly lead to more reviews, which means that lowering prices alone does not guarantee more customer attention. There was also no strong relationship between product price and rating, suggesting that more expensive products were not necessarily rated better than cheaper ones.

Another important finding was that some products had high discounts but still performed poorly in terms of engagement or ratings. This shows that discounting alone cannot solve deeper issues such as poor product quality or weak presentation. At the same time, the analysis identified a group of products with both strong engagement and high ratings, which can be seen as examples of successful listings on the platform.

Overall, this step turned the project from simple data preparation into real business insight. It showed that success depends on more than price cuts and that factors like product quality, description, and presentation are likely to have a bigger impact on performance.

Conclusion and Limitation

This project shows that data analysis is most valuable when it is based on careful cleaning, thoughtful assumptions, and clear interpretation. One limitation of the study is that it did not include direct sales, revenue, or product age data. Because of this, review counts had to be used as a proxy for customer engagement rather than a direct measure of sales performance. Some values also required estimation, such as price ranges, and rating groups were created through categorization, which introduced some assumptions into the process.

Another important limitation is that correlation does not mean causation. Even if two variables appear related, it does not prove that one directly causes the other. This means the findings should be interpreted carefully and not treated as absolute proof. Despite these limitations, the analysis still provided useful insights. It suggested that sellers should not depend only on discounts to attract engagement. Instead, they should focus more on product quality, listing presentation, and customer feedback.

In conclusion, the project demonstrates that successful data analysis depends on more than just creating charts. The real value lies in understanding the data, cleaning it properly, and using it to support better business decisions.

Getting Started with Excel for Data Analytics: From Basic to Data Cleaning

KingUSD — Wed, 02 Sep 2026 17:14:23 +0000

introduction

Every business, no matter how small or large, runs on data. Sales figures, customer records, inventory counts, expense reports — all of it lives somewhere, and more often than not, that "somewhere" is a spreadsheet. Before businesses invest in expensive analytics platforms or hire dedicated data teams, most of their real-world data problems can be solved right inside Excel.

The catch is that raw data is almost never ready to use. It's messy. It has duplicate entries, inconsistent formatting, blank cells, typos, and mismatched units. This is where data cleaning comes in — the unglamorous but absolutely essential first step of any analytics process. Analysts often say that 60–80% of the time spent on any data project goes into cleaning and preparing data before a single chart or insight is produced.

This article walks through how Excel, a tool most businesses already own and already know, can be used to solve real, everyday data problems — starting from the basics and moving into practical data cleaning techniques.

Why Excel Is Still Relevant for Data Analytics

With so many modern tools like Python, SQL, and Power BI available, it's fair to ask why Excel still matters. A few reasons:

Accessibility — nearly every business already has it installed.
Low learning curve — formulas and functions are intuitive compared to writing code.
Visual feedback — you can see your data change in real time as you clean it.
Powerful enough — features like Power Query, PivotTables, and advanced formulas can handle surprisingly large and complex datasets.
Universal file format — CSV and XLSX files are the common language most business systems export to.

For small and mid-sized businesses especially, Excel is often the fastest path from "raw data" to "business decision."

Common Business Problems That Start With Messy Data

Before diving into technique, it helps to understand why this matters. Here are real examples of business problems that trace back to poor data quality:

Duplicate customer records inflate marketing costs when the same customer is emailed twice.
Inconsistent date formats ("01/02/2024" vs "Feb 1, 2024") break sales trend reports.
Trailing spaces or inconsistent capitalization ("Nairobi " vs "nairobi" vs "NAIROBI") cause a location filter to miss half the relevant rows.
Blank or missing values in a revenue column throw off totals and averages.
Numbers stored as text silently break SUM formulas, giving a total of zero when data actually exists.

Each of these seems small in isolation, but multiplied across thousands of rows, they can quietly distort decisions — a manager might think a region is underperforming simply because half its data didn't get counted.

Part 1: The Basics — Getting Comfortable With Excel

Before cleaning data, it helps to be fluent in a few fundamentals.
_1. Understanding Rows, Columns, and Cells
Every dataset in Excel is a grid: rows represent records (e.g., one customer per row), and columns represent attributes (e.g., name, email, purchase amount). Getting this mental model right is the foundation for everything else.

2. Core Functions Worth Knowing Early
SUM(), AVERAGE(), COUNT() — basic aggregation
IF() — conditional logic (e.g., flag orders above a certain value)
VLOOKUP() / XLOOKUP() — pulling matching data from another table
COUNTIF() / SUMIF() — conditional counting and summing_

_3. Sorting and Filtering
Sorting reorders data (e.g., highest to lowest sales), while filtering temporarily hides rows that don't meet a condition. These two tools alone can answer a surprising number of business questions — "who are my top 10 customers this month?" — without any complex formulas.

4. Formatting for Clarity
Applying consistent number formats (currency, percentages, dates) isn't just cosmetic — it prevents Excel from misinterpreting values, which is often the root cause of calculation errors later._

*Part 2: Data Cleaning — Where the Real Value Is
*
Once the basics are comfortable, the next skill that separates a casual Excel user from someone who can actually solve business problems is data cleaning. Below are the most common techniques, explained with the business problem each one solves.

1. Removing Duplicates

Problem it solves: Duplicate customer or transaction records that inflate totals or cause repeated outreach.

Excel's built-in Data → Remove Duplicates tool scans selected columns and removes exact matches. For more nuanced duplicates (like "John Smith" vs "john smith "), combine this with the TRIM() and PROPER() functions first to standardize text before removing duplicates.

2. Trimming and Cleaning Text

Problem it solves: Inconsistent spacing and casing that breaks filters, lookups, and groupings.

TRIM() removes extra spaces.
CLEAN() removes non-printable characters (often hidden in data exported from other systems).
UPPER(), LOWER(), PROPER() standardize capitalization.

A common real-world case: a customer list exported from a CRM has "Muscat", "muscat ", and "MUSCAT" all representing the same city. Left uncleaned, a PivotTable would treat these as three separate cities.

3. Handling Blank or Missing Values

Problem it solves: Broken calculations and misleading averages.

Use Go To Special → Blanks to quickly locate empty cells, or wrap formulas in IFERROR() / IFBLANK() logic to handle them gracefully rather than letting them silently corrupt totals. For larger datasets, Power Query can automatically detect and either fill or flag blank values in bulk.

4. Fixing Numbers Stored as Text

Problem it solves: Formulas returning zero or #VALUE! errors despite visible numbers in the cells.

This is one of the most common — and most confusing — issues in business spreadsheets, especially with data exported from accounting or POS systems. A quick fix: select the affected cells, use Text to Columns (Data tab), and click through with default settings — this forces Excel to re-recognize the values as numbers.

5. Standardizing Dates

Problem it solves: Sales or booking trend reports that don't sort correctly or skip data due to mismatched date formats.

Excel often imports dates as text depending on the source system's regional settings. Using DATEVALUE() or Power Query's "Change Type → Date" function converts these into true date values Excel can sort, filter, and calculate against (e.g., "days since last purchase").

6. Splitting and Combining Columns

Problem it solves: Data crammed into a single column that needs to be analyzed separately (e.g., "Nairobi, Kenya" needs to become "City" and "Country" columns).

Text to Columns or the TEXTSPLIT() function (in newer Excel versions) can split data by a delimiter like a comma. Conversely, CONCATENATE() or TEXTJOIN() merges columns back together — useful for building full names or addresses from separate fields.

7. Using Power Query for Repeatable Cleaning

Problem it solves: Manually repeating the same cleaning steps every time new data arrives (e.g., a weekly sales export).

Power Query (Data → Get & Transform) lets you record a cleaning process once — remove duplicates, trim text, fix data types, filter out irrelevant rows — and then simply refresh it every time new data comes in. This turns a half-hour manual cleanup into a single click, which is enormously valuable for recurring reports.

8. Conditional Formatting to Spot Errors Visually

Problem it solves: Catching outliers, errors, or inconsistencies that are easy to miss by scrolling through rows.

Highlighting cells that fall outside an expected range (e.g., negative revenue, dates in the future, prices of $0) turns error-spotting into a visual task rather than a manual line-by-line review.

Part 3: Turning Clean Data Into Business Insight

Once data is clean, Excel becomes genuinely powerful:

PivotTables summarize thousands of rows into a digestible table in seconds — total sales by region, average order value by month, and so on.
Charts turn those summaries into something a non-technical stakeholder can understand at a glance.
What-if analysis tools (Goal Seek, Data Tables) let a business test scenarios, like "what happens to profit if costs rise 10%?"

None of this works reliably, though, if the underlying data is inconsistent — which is exactly why cleaning comes first.

A Simple Workflow to Follow

For anyone starting out, a practical end-to-end approach looks like this:

Import the raw data (CSV, exported report, etc.)
Inspect it — scroll through, check for obvious inconsistencies
Clean it — remove duplicates, trim text, fix data types, handle blanks
Structure it — split/combine columns as needed, standardize dates
Analyze it — PivotTables, formulas, charts
Automate it — where possible, use Power Query so the process repeats itself next time
Conclusion

Excel's reputation as a "basic" tool undersells what it can actually do. For most businesses, the real barrier to good decision-making isn't a lack of data — it's dirty, inconsistent data that hides the truth inside it. Learning to clean data properly in Excel — trimming text, fixing data types, removing duplicates, standardizing formats — is often the single highest-leverage skill a business analyst can develop, because it's the step that determines whether every analysis built afterward can actually be trusted.

Mastering the basics of Excel is the entry point. Mastering data cleaning is what turns Excel from a simple spreadsheet tool into a genuine business problem-solving instrument.

What will happen if Cloud database becomes too expensive ???

KingUSD — Mon, 24 Aug 2026 04:20:50 +0000

For most of the last fifteen years, "move it to the cloud" was the answer to almost every data infrastructure question. Storage was cheap, compute was elastic, and nobody had to rack a server again. But for the past 18 months, a lot has happened to the data world — and the bills caught up with them.
Walk into almost any engineering org running a modern data stack today and you'll hear some version of the same complaint: the Snowflake or Databricks invoice keeps climbing, nobody can fully explain why, and finance is starting to ask uncomfortable questions in planning meetings. This isn't a hypothetical problem anymore. It's the reason "cloud repatriation" has gone from a niche blog post topic to a boardroom conversation.

How we got there

The pitch behind cloud data platforms was simple: pay for what you use, scale up when you're busy, scale down when you're not. In practice, a few things went wrong.
Nobody scales down. Warehouses get provisioned for peak load and then just... stay there. Auto-suspend settings get ignored. Dashboards refresh every five minutes when once a day would do. The elasticity that was supposed to save money quietly turns into a fixed cost nobody revisits.
Compute and complexity crept up together. Every new dashboard, every new ML feature, every "quick" transformation job adds a little more load to a system billed by the second. Individually, none of it looks expensive. Collectively, it's a warehouse bill that's tripled in two years while the actual data volume barely changed.
A lot of workloads never needed distributed compute in the first place. Teams reached for Spark clusters and enterprise warehouses on datasets that would fit comfortably on a laptop. The industry over-engineered itself into complexity it didn't need, and now it's paying rent on that complexity every month.
Egress and lock-in quietly tax the exit. Once your data lives in a vendor's proprietary format, leaving isn't just a technical migration — it's a bill in itself. That friction keeps teams paying prices they'd otherwise walk away from.

What Happens When It Gets Too Expensive

When the cost curve stops making sense, teams don't usually abandon the cloud wholesale — they get selective about it. A few patterns are showing up consistently across the industry right now.

Repatriation of the boring, predictable stuff.
The workloads that run the same way every day — steady-state storage, routine batch ETL, standard reporting — are the easiest to move to cheaper infrastructure or bring back on-prem, because their resource needs are known in advance. The unpredictable, bursty workloads (ML training, seasonal spikes) stay in the cloud, where elasticity actually earns its premium. Dropbox and 37signals both made headlines doing exactly this and saving millions annually.
A shift toward "right-sized" compute.
This is the rise of tools like DuckDB and Polars: engines built to do serious analytical work on a single machine instead of spinning up a distributed cluster for data that never needed one. If your dataset fits in memory on a beefy laptop, you don't need to pay for a warehouse cluster to query it. It's less about rejecting the cloud and more about rejecting the assumption that everything needs cluster-scale compute by default.
Decoupling storage from compute — and taking it seriously.
Open table formats like Iceberg and Delta Lake, sitting on plain object storage (S3, GCS, or increasingly cheaper alternatives like Cloudflare R2), let teams keep their data in a durable, portable format while treating the compute engine as replaceable. Snowflake today, DuckDB or Trino tomorrow — same data, no re-platforming project required. This is arguably the single biggest structural defense against cost lock-in.
Choosing formats and vendors that don't punish you for leaving.
Egress fees and proprietary storage formats are a large part of why cloud costs feel inescapable. Betting on open formats isn't just a technical preference anymore — it's a negotiating position. When leaving is actually possible, vendors have to compete on price rather than lock-in.
Multi-cloud as leverage, not ideology.
Fewer companies are going multi-cloud for resilience these days and more are doing it because having a second viable vendor is the only thing that keeps the first one honest on pricing.

The Underlying Shift
None of this is really an anti-cloud movement. It's a correction. The industry spent a decade defaulting to maximum scale and maximum vendor convenience, and it's now relearning a lesson every infrastructure generation eventually learns: match the tool to the actual size of the problem, keep your exits open, and never let "it's just easier this way" become the whole cost strategy.
The teams handling this well aren't the ones chasing the cheapest possible stack. They're the ones who can actually answer the question "why does this cost what it costs?" — and who've built enough optionality into their architecture that if the answer ever stops making sense, they have somewhere else to go.

SSH Explained...

KingUSD — Thu, 20 Aug 2026 17:32:45 +0000

SSH stands for Secure Shell, a network protocol that allows someone to securely connect to and communicate with a remote machine over an unsecured network. Before SSH existed, tools like Telnet existed, but anyone could snoop the network and SSH fixed that by encripting the entire session.

The main parts of SSH

Transport Layer — Handles the initial connection, server authentication, and encryption setup. This is where the client confirms it's talking to the right server and both sides agree on an encryption algorithm to protect everything that follows.
Authentication Layer — Confirms who is connecting. This is where passwords or, more commonly, key pairs come in.
Connection Layer — Once you're authenticated, this layer manages the actual session: running commands, forwarding ports, transferring files, all multiplexed over the single encrypted connection.

How SSH authentication works

The most common and most secure way to authenticate with SSH is public key authentication, and it's worth understanding the flow rather than just trusting it works:

You generate a key pair on your machine (ssh-keygen). This produces two files: a private key and a public key.
You give the public key to the server or service you want to access — for example, pasting it into GitHub's SSH key settings, or appending it to ~/.ssh/authorized_keys on a remote server.
When you connect, the server sends a cryptographic challenge that can only be answered correctly by whoever holds the matching private key.
Your SSH client uses your private key to respond to that challenge — without ever sending the private key itself over the network.
If the response checks out, the server knows you hold the private key, and grants access.

This is the important part: your private key never leaves your machine, even during authentication. That's fundamentally different from a password, which has to be transmitted (even if encrypted) for the server to check it.

You can also authenticate with a password over SSH, but key-based authentication is standard practice because it's far more resistant to brute-force attacks and doesn't rely on you (or a service) remembering and protecting a secret string.

SSH vs HTTPS

HTTPS is the protocol most people are already familiar with from browsing the web. When used with Git, it authenticates you with a username and a password or personal access token, sent over an encrypted HTTPS connection.

SSH, as covered above, authenticates you with a key pair instead of a password or token.

Neither is objectively "more secure" in a blanket sense — both are strong when configured correctly. The real difference is convenience and threat model. SSH avoids ever transmitting a reusable secret and skips repeated prompts, which is why most developers set it up once and forget about it. HTTPS is faster to get started with and works everywhere, including networks or environments where SSH's port is blocked.

Could markdown become the next programming language?

KingUSD — Wed, 12 Aug 2026 10:52:12 +0000

Would it be interesting if all code would just be in plain english? Its a wild concept and AI agents like claude code are using structured .md files or "skill.md" to define entire repeatable workflows.

Markdown is not just for formating or writing articles anymore, its becoming a lightwieght way to program and easy to be understood by AI agents

Markdown has a whole ecosystem formed around it, MCP (Model Context Protocol), and AI harnesses that connect agents to real eternal tools. AI harnessing is scaffolding a model and turning it from a chatbot into something that can actually do things.

It has some limitations that doesnt make it a real trade off as per now August 2026, things like token cost, hallucinations and workflow entropy.

so with vast change in technology could markdown become the next programming language?