DEV Community: jan paul

How I use GBNF grammars to make small local models stop hallucinating JSON

jan paul — Wed, 29 Jul 2026 09:22:43 +0000

Or: why your 8B model keeps breaking your agent's tool protocol, and what you can do about it at the token level.

Originally published on eris-system.dev/blog/gbnf-grammars

I've been building Eris, a local-first AI agent written in Rust. It sits on your machine, reads and writes an Obsidian-compatible Markdown vault, and calls tools (memory, reminders, web fetch, email, calendar) through a structured JSON protocol. The LLM backend is llama.cpp, the models are 8-26B GGUFs, and nothing leaves your machine unless you explicitly opt in.

The single hardest engineering problem in the whole project wasn't the orchestrator, the TUI, or the semantic memory layer. It was this:

Getting a small local model to reliably emit valid, schema-conformant JSON.

This post is about how I solved it with GBNF grammars (compiled per-session and narrowed per-turn) and why I think this approach generalises to anyone building tool-calling agents on local models.

The problem: small models are sloppy with JSON

If you've tried to build an agent on a local 8B or even 12B model, you know the drill. You tell the model to respond in JSON. It does, mostly. Then on turn 47 it:

Forgets a closing brace
Adds a trailing comma in an array
Invents a tool name that doesn't exist (vault_read instead of vault:read)
Wraps its JSON in a markdown code fence
Emits valid JSON followed by a paragraph of conversational text
Returns "args": "path=notes/today.md" instead of "args": {"path": "notes/today.md"}

Ollama's format: json helps a bit. It constrains output to some valid JSON, but it says nothing about which JSON. Your tool protocol schema isn't enforced. The model can return {"sure": "here is your file"} and that's perfectly valid JSON. It just isn't a valid tool call.

OpenAI and Anthropic solve this with server-side function-calling APIs. But we're running locally. We don't have that luxury. We have something better.

GBNF: constraining generation at the token level

llama.cpp supports GBNF grammars, a BNF-like format that constrains which tokens the sampler is allowed to emit. If a token would produce a string that can't be extended into a valid parse of the grammar, it gets masked out before sampling. The model literally cannot generate malformed output. Not 'usually doesn't'. Cannot.

This is a fundamentally different thing from prompt-engineering the model to 'please respond in JSON'. It's a hard constraint on the sampler, enforced at every single token position.

Eris compiles a GBNF grammar at session start that defines the exact shape of its protocol envelope. Here's the skeleton from src/engine/grammar/envelope.rs:

const STATIC_GRAMMAR: &str = r#"root ::= "{" ws thought-kv "," ws status-kv "," ws message-kv "," ws toolcalls-kv ws "}"

ws ::= [ \t\n]*

thought-kv ::= "\"thought\"" ws ":" ws json-string
status-kv  ::= "\"status\"" ws ":" ws status-enum
message-kv ::= "\"message_to_user\"" ws ":" ws (json-string | "null")
toolcalls-kv ::= "\"tool_calls\"" ws ":" ws "[" ws tool-call-list ws "]"

status-enum ::= "\"Task\"" | "\"Reflect\"" | "\"Idle\"" | "\"Process\""
"#;

Every LLM response must be a JSON object with exactly four keys: thought (chain-of-thought, always present), status (one of four enum values), message_to_user (string or null), and tool_calls (array of name+args objects). The model can't deviate. It can't add a fifth key. It can't misspell tool_calls. It can't emit a status value that doesn't exist in the enum.

The tool call shape itself gets appended depending on whether we're in static mode (any JSON object for args) or dynamic mode (per-tool typed args):

/// Per-tool dynamic-args version: tool-call dispatches into `tool-with-args`.
const TOOL_CALL_RULES_DYNAMIC: &str = r#"tool-call-list ::= "" | tool-call ("," ws tool-call)*
tool-call ::= "{" ws "\"name\"" ws ":" ws tool-with-args ws "}"
"#;

Notice tool-with-args here. That's where it gets interesting.

Compiling JSON Schema to GBNF rules

Tool arguments are where small models really struggle. A vault:read call needs {"relative_path": "some/file.md"}. A web:fetch call needs {"url": "https://..."}. Without constraints, the model will happily call vault:read with {"file": "notes.md"} (wrong key name, schema validation fails, recovery turn wasted).

Eris goes further: it compiles each tool's JSON Schema into GBNF rules at startup. The schemas come from Rust structs via schemars, so the types are the source of truth. Here's the compiler entry point in src/engine/grammar/schema_to_gbnf.rs:

pub fn schema_to_gbnf_rule(
    tool_name: &str,
    schema: &RootSchema,
) -> Option<(String, Vec<GbnfRule>)> {
    let rule_name = tool_name_to_rule_name(tool_name);
    let mut ctx = CompileCtx {
        definitions: &schema.definitions,
        extra_rules: Vec::new(),
        depth: 0,
    };

    let body = compile_schema_object(&schema.schema, &rule_name, &mut ctx)?;
    let mut rules = vec![(rule_name.clone(), body)];
    rules.extend(ctx.extra_rules);
    Some((rule_name, rules))
}

A GbnfRule is just a (String, String) tuple: rule name and rule body. The compiler walks the JSON Schema tree and emits GBNF productions for each type it finds. Objects become key-value sequences with required fields unconditional and optional fields wrapped in (...)?. Strings with enums become GBNF alternations. Arrays get a helper list rule. $ref pointers get resolved against the definitions map.

The object compiler is the meatiest part. It sorts properties (required first, then optional, alphabetically within each group) and emits them with proper comma handling:

fn compile_object(
    validation: Option<&ObjectValidation>,
    parent_rule_name: &str,
    ctx: &mut CompileCtx<'_>,
) -> Option<String> {
    // ... validation checks, depth guard (MAX_DEPTH = 2) ...

    let required_set: std::collections::HashSet<&str> = validation
        .required.iter().map(|s| s.as_str()).collect();

    // Sort: required first (alphabetically), then optional (alphabetically).
    let all_fields: Vec<&FieldInfo> = required_fields
        .iter().chain(optional_fields.iter()).copied().collect();

    let mut parts = Vec::new();
    for (i, field) in all_fields.iter().enumerate() {
        let kv = format!(
            "\"\\\"{}\\\"\" ws \":\" ws {}",
            field.key, field.expr
        );
        if i == 0 {
            if field.required {
                parts.push(kv);
            } else {
                parts.push(format!("({kv} )?"));
            }
        } else if field.required {
            parts.push(format!("ws \",\" ws {kv}"));
        } else {
            parts.push(format!("(ws \",\" ws {kv} )?"));
        }
    }

    let body = format!("\"{{\" ws {} ws \"}}\"", parts.join(" "));
    Some(body)
}

So for a Rust struct like this:

#[derive(JsonSchema, Deserialize)]
struct VaultWriteArgs {
    relative_path: String,
    content: String,
    mode: WriteMode,  // enum: "overwrite" | "append"
}

The compiler produces GBNF rules roughly like:

vault-write-args ::= "{" ws "\"content\"" ws ":" ws json-string
                      ws "," ws "\"mode\"" ws ":" ws ("\"overwrite\"" | "\"append\"")
                      ws "," ws "\"relative_path\"" ws ":" ws json-string ws "}"

If the model emits "vault:write" as the tool name, the sampler forces the args to conform to vault-write-args. The model can't use the wrong key. It can't pass a number where a string is required. It can't use a mode value that isn't overwrite or append. The schema is literally part of the grammar.

Arrays work too. For a tool with tags: Vec<String>, the compiler emits a helper list rule:

fn compile_array(
    validation: Option<&ArrayValidation>,
    parent_rule_name: &str,
    ctx: &mut CompileCtx<'_>,
) -> Option<String> {
    let items_expr = match validation.and_then(|v| v.items.as_ref()) {
        Some(SingleOrVec::Single(item_schema)) => match item_schema.as_ref() {
            Schema::Object(obj) => {
                let item_rule = format!("{parent_rule_name}-item");
                compile_schema_object(obj, &item_rule, ctx)
                    .unwrap_or("json-value".into())
            }
            Schema::Bool(true) => "json-value".into(),
            Schema::Bool(false) => return Some("\"[\" ws \"]\"".into()),
        },
        // ...
        None => "json-value".into(),
    };

    let list_rule_name = format!("{parent_rule_name}-list");
    let list_body = format!("{items_expr} (\",\" ws {items_expr})*");
    ctx.extra_rules.push((list_rule_name.clone(), list_body));

    Some(format!("\"[\" ws ({list_rule_name})? ws \"]\""))
}

Which produces something like:

test-array-args-tags-list ::= json-string ("," ws json-string)*

The depth guard (MAX_DEPTH = 2) prevents the compiler from chasing recursive schemas forever. If a schema is too complex (deeply nested oneOf, recursive types, free-form additionalProperties with no fixed keys), the compiler returns None and the tool falls back to a generic json-object rule. Graceful degradation, not a crash.

Per-turn grammar narrowing: the real trick

Here's the thing that really moves the needle for small models: Eris doesn't give the model the full 50-tool grammar on every turn.

Before each LLM call, the orchestrator runs a ToolRouter, a semantic similarity search using the same embedding model as vector memory. The user's message gets embedded and compared against precomputed vectors for each tool (built from tool names, descriptions, and routing hints). Only tools above a cosine similarity threshold make the cut.

The GBNF grammar is then recompiled to include only those tools. If the user says 'what time is it', the grammar's tool-with-args alternation might contain only clock:now. The model can't call vault:write even if it wanted to. Those tokens simply aren't available to the sampler.

The subset cache lives in src/orchestrator/core/llama_gbnf_subset.rs:

pub(crate) fn get_or_compile_subset(
    &self,
    gatekeeper: &Gatekeeper,
    tool_names: &[String],
) -> Result<Arc<str>> {
    let mut sorted: Vec<String> = tool_names.to_vec();
    sorted.sort();
    let key: String = if sorted.is_empty() {
        CACHE_KEY_NO_TOOLS.to_string()
    } else {
        sorted.join("\x1e")  // ASCII record separator as cache key
    };

    let mut guard = self.inner.lock().map_err(|_| {
        FcpError::EngineFault("GBNF subset cache mutex poisoned".to_string())
    })?;

    if let Some(hit) = guard.get(&key) {
        return Ok(Arc::clone(hit));
    }

    // Cache miss: compile grammar for exactly these tools
    let entries: Vec<ToolGrammarEntry> = sorted
        .iter()
        .map(|name| {
            let per_tool_rules = gatekeeper
                .parameters_root_schema_for(name)
                .and_then(|schema| schema_to_gbnf_rule(name, &schema))
                .map(|(_rule_name, rules)| rules);

            ToolGrammarEntry {
                name: name.clone(),
                per_tool_rules,
            }
        })
        .collect();

    let compiled = compile_fcp_envelope_grammar_dynamic(&entries);
    let arc: Arc<str> = Arc::from(compiled.into_boxed_str());
    guard.insert(key, arc.clone());
    Ok(arc)
}

Same tool set on a different turn? Cache hit, no recompilation. The Arc<str> keeps the compiled grammar around cheaply.

And here's how the orchestrator picks which grammar to use on each LLM call, from the main cognitive loop in src/orchestrator/core/step.rs:

let (grammar_override, attach_session_grammar) = if !self.config.is_llamacpp() {
    (None, true)  // Ollama: no grammar support, skip
} else if !tools_needed {
    // No tools matched this turn: compile empty grammar (forces tool_calls: [])
    let g = self.gbnf_subset_cache
        .get_or_compile_subset(&self.gatekeeper, &[])?;
    (Some(g), true)
} else if !targeted_tools.is_empty() {
    // Recovery/retry: only the specific tools we're retrying
    let names: Vec<String> = targeted_tools.iter().cloned().collect();
    let g = self.gbnf_subset_cache
        .get_or_compile_subset(&self.gatekeeper, &names)?;
    (Some(g), true)
} else if slim_assembly {
    // Normal path: pre-LLM router's top-K matched tools
    let offered = slim_offered_tool_names(
        &pre_llm_matched_tools,
        self.tool_map_offer_cap,
        moltbook_overlay_latched,
        &self.gatekeeper,
        &self.state,
    );
    if offered.is_empty() {
        (None, true)  // fall back to full session grammar
    } else {
        let g = self.gbnf_subset_cache
            .get_or_compile_subset(&self.gatekeeper, &offered)?;
        (Some(g), true)
    }
} else {
    (None, true)  // full tool roster, session grammar
};

Four branches, four different grammar scopes. The !tools_needed case is fun: when the router decides the user is just chatting (no tools relevant), the grammar still enforces the protocol envelope but compiles with an empty tool list. That means tool_calls can only be []. The model simply cannot hallucinate a tool call when the router says 'this is just conversation'.

This has two effects:

Reliability goes way up. Fewer choices means fewer mistakes. An 8B model choosing between 3 tools is dramatically more reliable than one choosing between 50.
Generation is faster. A smaller grammar means less work for the constrained sampler at each token position.

The gatekeeper: defence in depth

Grammar enforcement is necessary but not sufficient. Even with a perfect grammar, the model can still call a tool with semantically wrong arguments (a valid path that doesn't exist, or an action that's not appropriate in the current agent state).

Eris layers a Gatekeeper on top (src/tools/gatekeeper.rs). Every tool call passes through it before execution:

pub async fn execute_tool(
    &self,
    state: &AgentState,
    name: &str,
    args: Value,
) -> Result<String> {
    // 1. State-based authorization
    if !Self::state_allows_tool(state, name) {
        return Err(FcpError::ToolFault {
            tool_name: name.to_string(),
            reason: format!("Tool not authorized in state {:?}", state),
        });
    }

    // 2. Normalize common LLM arg-naming mistakes before validation
    let args = normalize_tool_args(name, args);

    // 3. Runtime JSON Schema validation (belt and suspenders with grammar)
    let compiled_schema = JSONSchema::options()
        .compile(&schema_value)
        .map_err(|e| FcpError::Config(...))?;
    if let Err(errors) = compiled_schema.validate(&args) {
        return Err(FcpError::SchemaViolation(...));
    }

    // 4. Execute
    let result = tool.execute(args).await?;

    // 5. Semantic guard: empty results in Recover state are suspicious
    if state == &AgentState::Recover && result.trim().is_empty() {
        return Err(FcpError::ToolFault {
            tool_name: name.to_string(),
            reason: "Semantic Guard: Tool returned zero logic results during recovery"
                .to_string(),
        });
    }
    Ok(result)
}

The arg normalization is worth a mention. Small models frequently use slightly wrong key names: q instead of query, path instead of relative_path, top_n instead of max_headlines. Rather than wasting a recovery turn, the gatekeeper silently maps common aliases before validation:

fn normalize_tool_args(tool_name: &str, mut args: Value) -> Value {
    let Some(obj) = args.as_object_mut() else { return args };

    if tool_name == "web:search" {
        for alias in ["q", "search_query", "search"] {
            if let Some(val) = obj.remove(alias) {
                if !obj.contains_key("query") {
                    obj.insert("query".to_string(), val);
                }
            }
        }
        obj.retain(|k, _| WEB_SEARCH_KEYS.contains(&k.as_str()));
    }
    // ... similar blocks for web:fetch, web:find, news:today,
    //     vision:see, media:catalog (path -> relative_path) ...
    args
}

This is a pragmatic concession. The grammar enforces structure. The normalizer handles naming drift. The schema validator catches whatever slips through both.

What this looks like in practice

On the Ollama backend (no grammar), a long session with a 12B model hits about 3-5% protocol failures per turn. Malformed JSON, invented tool names, trailing prose after the JSON object. Each failure costs a recovery turn (re-prompt with the parse error), which burns context window and adds latency.

On the llama.cpp backend with GBNF, protocol failures drop dramatically. Short to medium sessions are essentially clean. But I won't claim zero failures: on long contexts where the model starts losing coherence, even grammar-constrained output can degrade. The grammar guarantees syntactic validity (the JSON will parse, the keys will be right, the enum values will exist), but it can't fix a model that fills every string field with garbage or repeats the same tool call in a loop because it's lost the plot at 28k tokens.

That's why Eris doesn't rely on the grammar alone. There's a bounded recovery loop that catches schema violations, empty tool results, and semantic nonsense, feeds the model a concrete correction, and retries with a capped budget. The grammar killed the easy failures (malformed JSON, invented tool names). The recovery loop handles the rest. I'll write more about that mechanism in a follow-up post.

The difference in session stability is still massive. A 100-turn session on Ollama reliably degrades; the same session on llama.cpp with grammar stays usable far longer. Just don't let anyone tell you it's a silver bullet.

Bounded generation: the other half

Even with a perfect grammar, generation can go wrong if the model fills its context window mid-response. llama.cpp will truncate, and your valid-so-far JSON becomes invalid because the closing braces never got emitted.

Eris sets n_predict (max tokens to generate) per call, calibrated to leave room in the context window for the response to actually finish. The grammar ensures structure; bounded generation ensures the structure has room to close.

The architecture, briefly

For context on where the grammar fits in the bigger picture:

Single Rust binary. ~270 source files, ~50 tools, three presentation surfaces (ratatui TUI, localhost web UI via Axum+SSE, optional Discord sidecar), all sharing one orchestrator.
Markdown vault as memory. Notes in an Obsidian-compatible directory tree. Tiered memory: ephemeral staging (in-process), committed (written to vault), semantic recall (Qdrant vector search over vault chunks). Turn-start prefetch embeds the user message and injects relevant memories into the system prompt before the LLM even runs.
No unsafe, no panics, no println. Production code uses ? propagation through a typed error taxonomy (FcpError). Diagnostics go through tracing to rotating log files under .fcp/telemetry/. Never to the TUI buffer. println! would corrupt the ratatui render.
Actor model concurrency. No Arc<Mutex<T>> shared state between threads (well, except the grammar cache, which is a cold path). Communication via tokio::sync::mpsc channels.

Should you do this?

If you're building an agent on local models and you need structured output: yes, absolutely. GBNF grammar enforcement is the single biggest reliability win I've made on this project. More impactful than prompt engineering, more impactful than model selection, more impactful than retry logic.

The key insight is that the grammar is not a prompt. It's not a suggestion. It's a constraint on the sampler. The model can't violate it any more than it can output a token that doesn't exist in its vocabulary. That's a qualitative difference from anything you can do with system prompts.

The tradeoff: you're coupled to llama.cpp (or any sampler that supports grammars; VLLM has experimental support, Outlines does it differently). You need to write or compile the grammar. And very complex schemas (recursive types, polymorphic unions) may not compile cleanly. But for the typical agent tool protocol (an envelope with a discriminated union of tool calls) it works beautifully.

Try it

git clone https://github.com/janpauldahlke/eris
cd eris && cargo build --release
docker run -d -p 6333:6333 -p 6334:6334 \
  -v eris-qdrant-data:/qdrant/storage qdrant/qdrant
./target/release/eris chat   # first run launches the setup wizard

The code is at github.com/janpauldahlke/eris. The project site is eris-system.dev. Apache 2.0. Stars and contributions welcome.

If you're working on local AI agents, structured generation, or Rust+LLM integration, reach out or open an issue.*

thinking to myself when setting up a project boilerplate

jan paul — Tue, 04 May 2021 17:33:39 +0000

this is a thinking out loud to myself.

how to prepare a SPA in different frameworks/libraries but also in angular

ng new create-react-app vue cli
enable router
enable i18n strategy
enable store / reduxy stuff
bind router into store
ensure your API with smthng like or curls / postmany stugff

test GET / POST/ UPDATE
brief moment of think: do we need to auth? if so handle auth token with like setLocalStorage

create an entityfolder for selected endpoint, (if angular, also create a module here!!)
create model/type declartion (only if typescript, which we prefer) of entities
create service to consume any http-client (eg axios) // consider auth process

test GET / POST/ UPDATE loadAll(), oneOneById(), postNew(), update(), delete() for selected entity

test servicemethods in bare minimum but routable component, most liekly in lifecycle method of given framework
from now on we would need to distungiush from framework to framework/library which should be more articles,

in angular -which we atm work with- we go with:

create routeresolvers
prepare actions / reducer / selectors from ngrx, naivly bind http service into the loadaction (we like ngrx-entity here)
access store in template and trigger action for udf to ensure actions work
create effect for entity -> loadAllEntity -> http-service -> dispatch loadAllEntitySucess, bind result into store
we forget about, register router, effect, store, store-router in module, considering it silently given from now on, knowing forRoot() and forFeature().
remove 3 from template
consume loadEntity from action in routeresolver -> which should also will trigger the effect -> which will trigger the http -> which will trigger store binding
bind observable/subscriber to store in template list view
prepare route for single entity
access route, write resolver that gains single entity from store / write actions..... from here on
rinse repaet

quod erat demonstrandum.

looking for a good vpn provider

jan paul — Sat, 09 Jan 2021 16:14:05 +0000

I just asked this on the Typescript Discord Channel -- Offtopic, but tought why not enhance my question radius.

[17:08] Paulquapper: could somone suggest my a VPN provider with

1. a documented (javascripty) API and
2. the feature torenew ip, for given city/country. Ideally non US, no US-Server provider.
3. "cost efficient" (paying annualy)

Need help to improve my usage of gatsby-image

jan paul — Thu, 19 Nov 2020 10:26:11 +0000

Hello fellow Gatsby'ers. Today i am comming with a question to you. I need to improve my bundle size, and therefore i want to rewrite my gatsby-image wrapper to be more efficient.

Consider my bundle

BUT: the 150 images itself are only 14MB in total, which means gatsby bloats it like crazy.

I know my code smell in terms of BIG-O, but, my poor excuse, i didn't knew another way than mapping over the result. Can you guys help me to improve here, considering:

const ImageLarge = props => {
  return (
    <StaticQuery
      query={graphql`
        query {
          allFile(filter: { sourceInstanceName: { eq: "assets" } }) {
            edges {
              node {
                relativePath
                name
                childImageSharp {
                  fluid(maxWidth: 600, quality: 100) {
                    ...GatsbyImageSharpFluid
                  }
                }
              }
            }
          }
        }
      `}

and here now my pile of shame:

 const image = data.allFile.edges.find(n => {
          return n.node.relativePath.includes(`${path + props.src}`)
        })

        if (!image) return null

Btw, my problem are comming from not beeing able to parametrize my static gqlquery with arguments, so i took all images, mapped over and returned only the image that i needed. horrible inifficnient.

Why cant i do something like this?

const ImageLarge = props => {
  return (
    <StaticQuery
      query={graphql`
        query {
          allFile(filter: { sourceInstanceName: { eq: `assets/${name}.png` } }) {
            edges {
              node {
                relativePath
                name
                childImageSharp {
                  fluid(maxWidth: 600, quality: 100) {
                    ...GatsbyImageSharpFluid
                  }
                }
              }
            }
          }
        }
      `}

I asked google and found this, which describes my problem perfectly, but offers no solution

"Believe it or not you cannot create a fully dynamic image component using a gastby-image without risking a (possibly very large) bloat in your bundle size. The problem is that static queries in Gatsby do not support string interpolation in it's template literal."

what-is-the-best-way-to-display-all-pictures-of-a-directory-in-a-gatsby-project

If one you could help me to solve this problem, i'd be glad and i also think, that we should write about it here, so others can find this googeling.

May the code be with you 🙏

Javascript Homeoffice Stream

jan paul — Thu, 12 Nov 2020 09:46:46 +0000

Hey fellow nerds,

out of boredom in the homeOffice era, i started my very "unique" frontend stream. Feel free to join and chit chat.

https://www.twitch.tv/paulquappe :-)

How to deal with real imposters?

jan paul — Thu, 12 Nov 2020 09:43:26 +0000

Since we all read a lot about imposter syndrom, we tend to see an unrecognized genius in our collegues.

BUT? How to deal with an actual real imposter in your job?

I have been hired for a nice project, JAVA Backend + REACT (SSR) Frontend, Webassembly, webGL and Azure, just to bring you some buzzwords. The run is planed for like 5 years, so to say, it is today already planned, what they want to do with the product in the future.

After 10 years of beeing a developer, mostly Frontend, but also JSP/jinja/smartie and other templating stuff, i decided to take this position for the following reasons:

the stack looks familiar, but also there are some new things
the lifetime of the project (to comparsion, most agency project last 3 months in coding)
there will be a new team formed, since we take the project over and make it an internal company project
my desire to become a senior developer (not only moneywise)

And when they hired me, they said, there will be an IT Team soon in our company. So far, so good.

Then "the corana" happened and it was decided to hire only the Senior Architect, the HR found a promising candidate. No, they don't liked the indian guys, sadly. Still i bet he was good at JAVA but bad in german (since iam german).
They offered the job to someone else. It is a handsome, very charming, young and old, 10 years of experience as team-leader "senior software architect".

Just after stalking him on xing (our german linkedin) i realized, that his buzzwords never fit to each other. he has 4 star experience in C++/C#!!

??
!!

WTF, in either one, or in both? i mean for me, its been worlds between microsoft .NET and C++, but ok...

Then he has 4 Stars in JAVA/Android Studio? Hu? Java OR android or both or what? Iam confused.

But, i am the smallest lightbulb in the world, so they hired him, and he gets paid well, since i know my salary, which is pretty ok, but it is not the money i am about.

After talking to him for an hour, i realized he mixes terminology up. From my experience, if i dont develop daily, skills decay. I forget things, even the any type in Hypescript (joke is on me).

I wonder if it is reasonable to think, that someone who has not been in coding for 10 years, since his resumee is saying "PROJEKT MANAGER" and not "DEVELOPER", simply can not code.

We talked. He didn't know that JAVA servers are configurable for the MEM they are allowed to use.
He has no ****ing clue about JAVA changing it's business model and versioning, openjdk vs oracle java.

He messes up PUT and POST and sends the same JSON-body on the same route, and asks me after two hours "why is this not working" (we use a swagger).

So i told him: "please be honest, how good is your JAVA?"
He replied: "i can learn fast, iam just learning spring boot on udemy right now."
And then he said, and this made me really listen up. "In the job description the where looking for a nodejs guy", So his resume has 4 of 5 stars in JAVA/android, but he applied for nodejs?

JEZ. I get confused about all the wrong buzzwords and project manager gibber he is talking.

My boss asked me, what i think about my new collegue. What would you say in this moment? I tend to be diplomatic. "He is really nice. I like him. I hope he can show me things in backend, that will make me senior in 4-5 years too."

I know this differs to the usual dev.to stuff, it's more a writeup. But let me get to the point.

I think he is an imposter, since he knows what is paid in IT.

How would you react if you find out your colleque is a liar about his skillset, wirite some tipps in the comments.

TL:DR
Among all the smart guys with imposter-syndrome, are some real imposters, for the lulz and the $$$$

console.fun() or how to mess up the DOM

jan paul — Wed, 13 Mar 2019 19:15:11 +0000

I stumbled upon this little gem in the vue-land #random channel and it made me smile. Posted by xan#2554.

Thought maybe it can make you smile too and decided to share it to you. Have fun.

Instructions

copy script

visit your most preferred website -- ..most likely dev.to 😜

open console

paste script and press enter

(function funnyFunction() {
  var screenwidth = window.innerWidth;
  var screenheight = window.innerHeight;
  document.querySelectorAll('body *').forEach(function(node) {
    randT = Math.floor(Math.random() * screenheight);
    randL = Math.floor(Math.random() * screenwidth);
    node.setAttribute('style', 'transition-duration:500ms; transition-property: left, top; position: fixed; top:'+randT+'px; left:'+randL+'px');
  });
  setInterval(funnyFunction, 500);
})();

Be honest to yourself, did you knew what will happen?

cheers

i installed a 9 month old mini project again

jan paul — Fri, 09 Nov 2018 09:08:29 +0000

I installed a npm project again after 9 months...
The package.json contained less then 10 entries.

This feels insecure, somehow.... but iam not an expert ;-)

How to improve the build speed in React-Typescript, when using material ui

jan paul — Mon, 22 Oct 2018 09:44:47 +0000

Hi,
you are using material - ui in react typescript and having trouble with the performance? Well i stumpled upon the same issue.
The build takes like forever, since i started to use material-ui and i was really no fun to code against such a lame project.

But lets go in medias res and describe the scenario:

I wrote a header component like this
Header. Pretty staright forward, right?

While coding i went really unhappy, because the build and the livereolad grew pretty slow. So i played around with the Typescript compiler and found this little command
tsc --diagnostics --listFiles which i made an alias healtcheck in my package.json.

Running it was painfull and ended in results like

Files:          5598
Lines:        108833
Nodes:        453997
Identifiers:  146625
Symbols:      217251
Types:         56743
Memory used: 300772K
I/O read:      4.66s
I/O write:     0.48s
Parse time:   26.90s
Bind time:     1.62s
Check time:    9.72s
Emit time:     1.64s
Total time:   39.87s

As you guys can easily see, it takes quite some time and runs to a TON of files.

I imported the two icons for the header like this:

import {
  AccountCircle,
  Language
} from '@material-ui/icons';

And i was wondering about the mass of files that --diagnostics considered when building, especially the trillions of /node_modules/@material-ui/icons/**.d.ts.

Yes iam a typescript user, and althought i had some troubles to get into it, i really like it now. As you might know, if a package does not bring its own typings, there is a huge community in DefinitlyTyped on github, that provides typings for large packages.

For example: one would get the typings for material-ui like this: npm install --save-dev @types/material-ui, with the result of beeing able to consume material-ui in the typescript world.

But a build time of nearly 40seconds? I wanted to improve this and did some research at big brother.
Found this github issue that point to the same problem. And i was really happy to read this comment with a major improvement.

Instead of importing like above, i simply rewrote my import of the icons to:

import AccountCircle from '@material-ui/icons/AccountCircle';
import  Language from '@material-ui/icons/Language';

Lets see how much this impacts our healtcheck now:

Files:           382
Lines:         98396
Nodes:        386176
Identifiers:  130972
Symbols:      201601
Types:         56743
Memory used: 245687K
I/O read:      0.35s
I/O write:     0.37s
Parse time:    4.29s
Bind time:     0.79s
Check time:    5.16s
Emit time:     1.44s
Total time:   11.69s

Wow! Iam was speechless by such a little change, but with an impact like this. We gained nearly 30seconds by altering 2 lines, i mean it could be more lines, but by NOT IMPORTING VIA THE INDEX.

Iam glad i could share this to you, and it will maybe help the one or another.

My name is JanPaul and iam working for instant-data. We are small company, that provides internal tooling for large agencies and also data-exchange platforms.

May the code be with you :pray:
Thanks for the title image to Emil Bruckner @unsplash.

reducks, a boilerplate

jan paul — Tue, 11 Sep 2018 18:27:54 +0000

img by Jase Ess

Hello dear dev.to,

Iam working for instant-data. a small company that provides solutions in the environment of a larger advertising agency. mostly internal toolings.

After playing round a little with the create-react-app, i wanted to share my latest boilerplate with you and ask for your opinions, or improvements. You can visit me here on github.
In this i follow the ducks pattern, in which you try to keep all your redux and store reducer stuff in one single file, but for sakes of DRY, i will present you the README.MD. I appreciate any feedback ;-)

It is created via the CLI-Tool

create-react-app <your-appname> --scripts-version=react-scripts-ts

and customized to my needs, by running

npm eject

Prequisites

Installed node and npm Version 8 or higher.

Available Scripts

In the project directory, you can run:

`npm start`

Open http://localhost:3000 to view it in the browser.

`npm run build`

Builds the app for production to the build folder.

`npm run seed` Authentication seed

To make the boilerplate work from scratch, and to simulate the flow of Auth, we put a JSON-Server.
You should remove the complete seed folder, or better add it to your .gitignore, when you implement your own workflow. To make use of it simply npm run seed. You will get served at json-server --port 4000 --watch -- seed/db.json.

Folder Structure

After creation, your project should look like this:

my-app/
  README.md
  node_modules/
  package.json
  public/
    index.html
    favicon.ico
  seed/
    /* a helper fake backend for firsttimers */  
  src/
    index.tsx
    components/
      App.tsx
    containers/
      /* your connected containers here */
    ducks/
      /* your ducks here */
    services/
      /* put all your global helpers inside here */
    store/
      history.ts
      index.ts
      localStorage.ts
  types/
    /*your types go here */

Debugging and DevTools

I strongly suggest you to install and use theses BrowserExtensions.

Material-UI and Decorators

The experimental feature for Decorators is activated in the tsconfig.json. By this it is possible to use the withStyle decorator in combination with compose of the recompose package.
Example usage is:

import { compose } from 'recompose';
import { withStyles } from '@material-ui/core/styles';

@(compose(withStyles(styles)) as any)
class Example extends React.Component<IExampleProps, IExampleState> {...}

To make use of themes in material-ui we need to wrap the content of App inside a

<MuiThemeProvider theme={createMuiTheme()}>
  //any content here
</MuiThemeProvider>

Environment

There is the possibility to provide ENV variables. use the .env file for this.
Please note, they need to follow the naming convention of REACT_APP_ EXAMPLE=FOOBAR.
Inside the project one can consume them by proccess.env.REACT_APP_EXAMPLE.
At a new start its set to the seedings path, so one might want to change it there.

HTTP Requests

Please use axios for your requests. It supports Promises and also async/await.
https://github.com/axios/axios
Also make sure the allow crossorigin-access on your server.

Ducks

We follow the 'Ducks'-Pattern to structure our application. Get insights on this specc here
https://github.com/erikras/ducks-modular-redux
The pattern is to have all these inside one duck:

action enum
action types
action creators
reducer functions
mainreducer
thunk
initialStore

Message Component

There is a rudimental example prepared in this boilerplate, that shows usage and consumption of a high level message or notification-component. Import the NofictationDuck inside the Ducks that you want the NotificationStore to be catched.

import NotificationDuck from '~/src/ducks/notification';

your.action()
  .then(() => /* success */)
  .catch((err) => {
      dispatch(NotificationDuck.throwNotificationWithError({text: 'your text', title: 'your title'}))
  })

But you can also connect them directly to components. Please keep in mind to reset the NotificationStore, with the RESET_NOTIFICATION_STORE action!

Store

Use the folder src/store to configure the store of redux according to your needs. There is also the possibilty to subscribe parts of the store to your localStorage. To do so check the index.ts and have a brief look at the store subscribe pattern.

store.subscribe(throttle(() => {
  const storage = store.getState() as RootState;
  const AuthStore = storage.AuthStore;

  saveState({
    AuthStore
  } as RootState);
}, 300));

Please make use of the throttle lodash-helper. JSON.parse()/JSON.stringyfy are expensive in Javascript.

Services

Anything you want to consume repetitive belongs to the services. Another word could be globalHelpers.

apicontroller -> an axois instance the can be configured. import it into your ducks to make http-verbs.
authenticationService -> can be used in conjunction with apicontroller inside of ducks to verify auth-Status

inside your duck - an example usage in thunk

import axios from '../../services/apicontroller';

public static getAuth() {
    return function (dispatch: any, getState:() => RootState): Promise<void> {
      dispatch(AuthDuck.getAuthAction());

      //return the axois object with header, pass the state by `getState()` to auth and GET the route with `get('/yourRoute')`

      return axios(getState()).get('/Authentication')
        .then((res) => {
          dispatch(AuthDuck.getAuthSuccessAction(res.data));
         })
        .catch((err: Error) => {
          /**
        });
    };
  }

There is also a whole react-router v4 part, i will explain at 50 :heart: :-)