标签：#programming

TLDR tsc is the TypeScript compiler. It turns your .ts files into .js files that Node.js and browsers can run. Install it with npm install -g typescript . Run tsc to compile your whole project. Run tsc --watch to auto-compile on every file save. Run tsc --noEmit to check for errors without creating any files. What is the TypeScript Compiler? The TypeScript compiler is a tool called tsc . It reads your TypeScript files and turns them into JavaScript files. Your browser and Node.js cannot run TypeScript directly. They only understand JavaScript. So tsc acts as the bridge between what you write and what actually runs. Think of tsc like a spell checker for your code. It finds problems before your code ever runs. Then it produces clean JavaScript output for you. How to Install the TypeScript Compiler You install tsc using npm. There are two ways to do this. Option 1: Global Install (runs anywhere on your computer) npm install -g typescript After install, check it works: tsc --version You will see something like Version 6.0.3 . Option 2: Local Install (recommended for teams) npm install --save-dev typescript Then run it using npx : npx tsc --version Which one should you use? Use a local install for project work. This makes sure everyone on your team uses the same TypeScript version. Use a global install only for quick personal experiments. How to Compile a Single TypeScript File The simplest way to use tsc is to pass it a single file. Create a file called hello.ts : const message : string = " Hello, TypeScript! " ; console . log ( message ); Now compile it: tsc hello.ts This creates a new file called hello.js in the same folder: var message = " Hello, TypeScript! " ; console . log ( message ); Notice that TypeScript removed the : string type annotation. The output is plain JavaScript that Node.js can run. Run the output file: node hello.js # Hello, TypeScript! Important: When you pass a file directly to tsc , it ignores your tsconfig.json . It uses its own default setting

This is a story about a company that rolled out an AI interview system — and the lunch break I spent...

Something changed in software engineering, and I do not think we have fully named it yet. For years, the job was mostly about writing code directly. Then autocomplete got better. Then chat-based coding assistants arrived. Now the workflow is shifting again: we describe goals, hand off chunks of work to agents, inspect their output, tighten the tests, and decide what gets merged. That is not the same job with a faster keyboard. It is a different shape of work. I would call it agentic engineering. The engineer is becoming a director Agentic engineering does not mean the engineer disappears. If anything, it makes the engineer's judgment more visible. A coding agent can read files, make changes, run commands, open pull requests, and iterate through errors. GitHub describes Copilot agent mode as a workflow where the agent can plan, edit, run terminal commands, and keep working until a task is complete. Google describes Jules as an asynchronous coding agent that can take a task, work in a virtual machine, and produce a pull request. Anthropic's Claude Code guidance talks openly about using multiple Claude sessions in parallel, giving agents clear context, and treating them like workers that need direction. That is the shift. The engineer is no longer only the person typing every line. The engineer is also the person deciding what should be built, what constraints matter, how to verify the result, and when the agent is wrong. Prompting is too small a word for this People often describe this work as prompting, but that undersells it. A prompt can be a single instruction. Agentic engineering is more like delegation. You define the task, provide the relevant context, set the boundaries, create checks, review the work, and decide the next move. If the agent goes in the wrong direction, the failure is not always the model's fault. Sometimes the task was too vague. Sometimes the repository had no tests. Sometimes the acceptance criteria lived only in someone's head. This is why

On June 9, 2026, Anthropic shipped the most capable model it has ever released to the public. The most interesting thing about it is the part that sometimes refuses to talk to you. Claude Fable 5 is the first model from what Anthropic calls its Mythos class, a tier that now sits above Opus. It launched as a pair. Fable 5 is the public version. Claude Mythos 5 is the same underlying model with its guardrails loosened, and it is not for sale to most of us. It goes only to vetted cyberdefenders and infrastructure providers through a program called Project Glasswing, in collaboration with the US government. Two names, one brain. The thing that separates them is a set of classifiers. That detail is the whole story, and almost every launch-day write-up buried it under the benchmark chart. So let me start there instead. One Model, Two Names, One Classifier in Between Fable 5 ships with three classifiers running alongside it. They watch for requests about offensive cybersecurity, about biology and chemistry that edge toward weapons, and about distillation, which is using the model to train a competitor. When a classifier fires, Fable 5 does not answer. The request gets handed to Claude Opus 4.8, the model that was the top of the public stack until that morning, and Opus answers in Fable's place. For anyone building on the API, this is not an abstract safety story. It is a response shape you have to handle. A refused request comes back as stop_reason: "refusal" with a normal HTTP 200, not an error, and it tells you which classifier tripped. You can have the API retry on another model with a fallbacks parameter, or do it client side with the SDK middleware. You are not billed for a request that is refused before it generates output. { "stop_reason" : "refusal" , "stop_sequence" : null , "content" : [] } Anthropic says this is rare. Its early numbers put at least 95 percent of Fable sessions running entirely on Fable's own answers. I believe that for general work. But "rare on

Το πρόβλημα της ώρας Η ώρα είναι από τα πιο ύπουλα προβλήματα στην ανάπτυξη λογισμικού. Αν ένας χρήστης στην Αθήνα δημιουργήσει μια παραγγελία στις 20:00 και ένας άλλος στη Νέα Υόρκη τη δει στις 13:00, ποια είναι η "σωστή" ώρα; Αν μια εφαρμογή αποθηκεύσει μόνο το 20:00, χωρίς να γνωρίζει τη ζώνη ώρας, τότε η πληροφορία είναι πρακτικά άχρηστη. Αυτός είναι ο λόγος που υπάρχουν έννοιες όπως: Local Time UTC UTC Offset Epoch / Unix Timestamp Δεν δημιουργήθηκαν για να μας μπερδεύουν. Δημιουργήθηκαν για να λύνουν το πρόβλημα της παγκόσμιας διαχείρισης χρόνου. Local Time Το Local Time είναι η ώρα που βλέπει ο χρήστης στη χώρα του. Παραδείγματα: Αθήνα: 2026-06-09 20:00 Λονδίνο: 2026-06-09 18:00 Νέα Υόρκη:2026-06-09 13:00 Όλες οι παραπάνω ώρες μπορεί να αντιστοιχούν στην ίδια ακριβώς χρονική στιγμή. Συνέβει ένα γεγονός μία ενέργεια στον πλανίτη γη ακριβώς αυτή την στιγμή που όμως για διαφορετικές γεωγραφικές περιοχές αντιστοιχεί σε διαφορετικές ώρες. Πότε χρησιμοποιούμε Local Time; Μόνο για εμφάνιση στον χρήστη. Παραδείγματα: Ημερομηνία παραγγελίας Ώρα δημιουργίας post Ημερολόγιο συναντήσεων Reports προς τον χρήστη Πότε ΔΕΝ το αποθηκεύουμε; Σχεδόν ποτέ ως μοναδική πηγή αλήθειας. Αν αποθηκεύσεις: 2026-06-09 20:00 δεν γνωρίζεις: Σε ποια χώρα δημιουργήθηκε Σε ποια ζώνη ώρας ανήκει Αν ίσχυε θερινή ώρα (DST) UTC (Coordinated Universal Time) Το UTC είναι η παγκόσμια αναφορά χρόνου. Όλες οι ζώνες ώρας υπολογίζονται σε σχέση με αυτό. Παράδειγμα: UTC: 2026-06-09 17:00 Την ίδια στιγμή με βάση την UTC ώρα μπορούμε να έχουμε: στην Αθήνα UTC+3 -> 20:00 στο Λονδίνο UTC+1 -> 18:00 στη Νέα Υόρκη UTC-4 -> 13:00 Πότε χρησιμοποιούμε UTC; Σχεδόν πάντα στο backend. Αποθηκεύουμε: 2026-06-09 T 17 : 00 : 00 Z Το Z σημαίνει UTC. Γιατί; Επειδή: Δεν αλλάζει με DST Δεν εξαρτάται από χώρα Είναι παγκόσμιο σημείο αναφοράς Ένας κανόνας που ακολουθούν σχεδόν όλες οι μεγάλες εταιρείες: Store in UTC, display in Local Time. UTC Offset Παραδείγματα: UTC+3 UTC+2 UTC-5 UTC+9 Για την Αθήνα: Χειμώνας -> UTC+2 Καλοκα

Hey everyone, I got tired of the usual configuration mess in C—manually writing tedious boilerplate to traverse generic JSON/YAML nodes, casting strings to integers, and writing a dozen if statements to handle out-of-range ports or missing environment variables. Worse yet, managing string lifetimes across nested configuration objects. To fix this, I built cfgsafe , an Ahead-of-Time (AOT) schema-driven configuration engine for C99. Instead of processing raw files at runtime, it takes a simple schema file and generates a type-safe, single-header library. I wrote a deep-dive engineering breakdown detailing the philosophy, memory model, and design choices behind it here: Type-Safe Configs in C99: Why I Prefer Code-Gen over Parsing And the github repo: CfgSafe How it works: Define a Schema: You use a simple DSL to declare fields, defaults, constraints (ranges, regex patterns), and sources (Env, CLI flags). Generate: The cfg-gen tool outputs a native C struct with matching validation primitives built straight in. Load Atomically: At startup, you make one call to Config_load . If a field is invalid or missing, it fails fast before your application's hot path even executes. A few specific architectural choices I made: Atomic Memory Pool: To prevent fragmented heap allocations and memory leaks, the generator bundles all incoming string/array values into a single contiguous memory block. Freeing the entire config is reduced to a single call to Config_free() . Zero Overhead Lookups: Because it compiles down to a native C struct, looking up a setting is just a basic memory offset rather than an $O(\log N)$ hash-map lookups or string comparisons. Compile-Time Safety & IDE Autocomplete: If you typo cfg.db.prt instead of cfg.db.port , the compiler refuses to build the app, and your editor knows exactly what fields exist and their data types. Strict Layering & Security: It bakes a strict precedence chain (CLI Arguments > Environment Variables > INI File > Schema Defaults) right int

Shareable blog post edition: https://andymaleh.blogspot.com/2026/06/andys-laws-of-ai-in-software-engineering.html Law #1: "The more Software Developers use AI, the more valuable Software Engineers who do not use AI become." Software Engineers who are masters at delivering Software without using AI will actually have increased job security the more Software Developers in the worldwide Software Development community rely on AI to deliver Software without having true mastery over Software Engineering. As more Software Developers become fully dependent on AI to build Software without truly understanding how AI gets work done, Software Engineers who do understand what is going on under the hood will dwindle and become more valuable than ever. In other words, they will have a competitive advantage over Software Developers who can only deliver Software features with AI as well as Software Developers who have not mastered Software Engineering. Also, there will always be a need for Software Engineers who can maintain the Software of AI itself. Law #2: "Software Developers benefit from AI in direct proportion to how weak they are in Software Engineering" The weaker Software Developers are at Software Engineering the more they benefit from AI. After all, AI learns from Master Software Engineers and then applies its learnings in code generation done for lower-level Software Developers who lack mastery in Software Engineering. So, users of AI simply place themselves lower in the expertise hierarchy to be on the receiving end of what Master Software Engineers feed AI with their code. This explains why many experts like Linus Torvalds do not find AI very useful while devs who have zero degrees and qualifications feel like they get a lot from AI. A beneficial thing to learn from this law is that it is more valuable for a Software Developer to hone in their Software Engineering skills (including the completion of university degrees) than to hone in their AI usage skills because if t

submitted by /u/DataBaeBee [link] [留言]

submitted by /u/elizObserves [link] [留言]

AI in 2026 is no longer best understood as a technology trend. It has become a structural layer...

we saw that multiple github repos name as Miasma-Open-Source-Release started appearing yesterday which was pushed by a compromised developer accounts. then we pulled the source to dig deeper. And calling it a worm would be very small its kind of a complete supply chain framework you can see which is having ARCHITECTURE .md integration test etc. so it was kind of a product. ARCHITECTURE.md was saying that it requires no C2 infrastructure and not have to deal with takedowns or maintaining infrastructure. it just stolen github PATs is only what is necessary. submitted by /u/BattleRemote3157 [link] [留言]

submitted by /u/jxd-dev [link] [留言]

We went through hundreds of StackOverflow + Reddit threads on ClickHouse and after seeing the same pain points surface repeatedly, we wrote up the 5 most common ClickHouse mistakes engineers make in production: Expecting ReplacingMergeTree to deduplicate reliably. It does, but eventually and not synchronously Picking the wrong table engine (MergeTree when you need Aggregating/Replacing) Treating PRIMARY KEY like it enforces uniqueness (it doesn't and ORDER BY column order matters far more) Too Many Parts errors from small inserts. Almost always fixable with batching JOINs behave differently than PostgreSQL. Smaller table must go on the right Check the concrete fix for each of them, with SQL examples: https://www.glassflow.dev/blog/clickhouse-mistakes-engineers-make?utm_source=reddit&utm_medium=socialmedia&utm_campaign=reddit_organic Happy to discuss any of these in the comments, especially the dedup one, which seems to trip up almost everyone coming from a relational background. submitted by /u/glassflow-dev [link] [留言]

submitted by /u/Dear-Economics-315 [link] [留言]

submitted by /u/andersmurphy [link] [留言]

AI coding agents feel sharp when a project is small. They can scan a few files, understand the shape, and make useful changes. In that phase, the project still fits inside the agent’s short-term memory. The architecture is obvious. The dangerous files are nearby. The blast radius is small. But something changes when a project reaches MVP size. The agent still sounds confident, but it starts guessing. It finds a nearby file and assumes it is the right one. It trusts stale documentation. It misses hidden callers. It forgets architecture boundaries. It edits something that was not really part of the task. I kept running into that problem while building larger projects. Source-level guardrails help. A CONTRIBUTING.md, AGENTS.md, or project instruction file can tell the agent how to behave. But those are still instructions. They are not facts. That is where the idea for CodeMeridian came from. What CodeMeridian is CodeMeridian is a local code knowledge graph for AI coding tools. It indexes a codebase into Neo4j and exposes that graph through MCP, so tools like GitHub Copilot, Claude Code, Codex-style agents, or other MCP-compatible clients can ask better questions before editing. The basic idea is: The assistant is the AI. CodeMeridian is the project map. It does not replace the coding assistant. It gives the assistant a structured way to ask about the codebase. Examples: What calls this method? What tests cover this area? What files are likely in scope for this feature? Is the graph stale before I trust it? How is this frontend component connected to backend code? Why a graph? Code is already a graph. Methods call methods. Classes implement interfaces. Tests cover production paths. Frontend components call API clients. API handlers touch services. Services use repositories. Docs mention symbols. Projects depend on other projects. A normal file search can find text. A graph can answer relationship questions. That matters because many AI coding mistakes are relationship m

Hello, I'm Maneshwar. I'm building git-lrc, a Micro AI code reviewer that runs on every commit. It is...

submitted by /u/Efficient-Public-551 [link] [留言]

The first post went over some of its capabilities. Over the past week Edict went v1.0, adding cursors for reading projections after command dispatch (to close some eventual-consistency gaps), a new type of projection that holds state inside the Orleans grain directly instead of a table, saga timeouts, schedules, an improved skills package and MCP server that ships with Edict, and more. Edict has now grown to over 75,000 lines of code and more than 1000 tests, and contains several deep mechanisms that have been fixed, broken, and fixed again. It is well past the point where I can hold all of Edict in my head. This post is about working with AI on large codebases, which I expect to be the first problem most software engineers have to solve. The context problem Years ago I was talking to a PhD candidate whose area of research was Natural Language Processing (NLP). He explained to me that one of the most difficult NLP problems was context. If a colleague says they need to pop out to pick their kids up from school, a scene can form in your head: one with a school, the layout of the road, people waiting, walking, driving, the environs. You may never have seen the school your colleague mentioned, but you can form a rich scene from your accumulated experience and use it to drive the rest of the conversation with a shared understanding. LLMs ingeniously dodge this entire issue by making it your problem. Just a word-probability machine Strip away the chat window and a Large Language Model (LLM) is doing one thing: predicting the next token. Give it a run of text and it returns a probability distribution over what comes next, samples one, appends it, and repeats. Companies like OpenAI and Anthropic then beat it into shape using techniques like supervised fine-tuning and reinforcement learning, which tune those probabilities in meaningful ways. That is why Claude is always telling me "Good framing" or "You've spotted...". It even called me "Bold" on one occasion. The probabilit

Something I keep noticing across teams and orgs that are actually getting value from AI versus the ones that aren't. The difference rarely comes down to the model or the algorithm. Most organizations are already drowning in data. Logs, metrics, alerts, reports, dashboards, tickets. The information exists. The bottleneck is what happens after the data shows up. How long does it take to interpret what the signal means? Who decides what to prioritize when three things need attention at once? How fast can the right people coordinate a response once a decision is made? That's where AI actually earns its keep. Not by replacing the human in the loop but by compressing the time between something happening and someone doing something useful about it. Signal to understanding to action. That's the chain that matters. Think about it in terms you deal with every day. A vulnerability gets disclosed. The CVE exists, the advisory is public, your scanner picked it up. None of that is the bottleneck. The bottleneck is figuring out which of your services are affected, who owns them, how bad the exposure actually is in your specific context, and getting a patch scheduled before someone exploits it. AI that helps you answer those questions in minutes instead of days is genuinely valuable. AI that and adds another dashboard to look at isn't. This applies across the board. Incident response, infrastructure management, risk assessment, customer systems, operational workflows. The teams getting real value aren't the ones with the fanciest models. They're the ones who figured out where their decision bottlenecks actually are and pointed AI at those specific gaps. The strategic advantage is rarely in the algorithm. It's in organizational responsiveness. How fast can you go from "something happened" to "we're handling it". The AI is just the thing that compresses that timeline. Where's the biggest decision bottleneck in your current workflow?