Posts

Visual Query Builder

Visual Query Builder    I built a visual query builder for an employer that built software in the past.  Was thinking about rebuilding it using Claude Code, picking Microsoft SQL Server for the database, and making it open source.  Starts with a known database.  Dynamically pick data (tables and rows using the system view information schema).  Have interface that filters, allows summarization (sum or count) by a secondary data (table and specific row), and allows sorting (and pick ascending or descending). When picking it shows a grid that is the Preview of the data. https://www.metabase.com/docs/latest/questions/query-builder/editor

Rust

Rust Super Powers: Memory Safety Without a Garbage Collector No Null or Dangling Pointers: The compiler tracks variable lifespans so runtime memory bugs are caught before the code ever runs.  "If Compiles Then It Works". The Borrow Checker: Ensures data is owned or borrowed correctly, stopping memory leaks and buffer overflows automatically. Zero-Cost Abstractions: High-level code features compile down to efficient machine instructions with no runtime overhead.  You can chain high-level methods like .map() , .filter() , and .fold() to process data rather than FOR loops. Fearless Concurrency No Data Races: The type system prevents multiple threads from mutating the same data unsafely at the same time. Parallel Processing: You can write multi-threaded code with confidence because the compiler rejects unsafe parallel patterns.

Azure Service Bus

Azure Service Bus Legacy was MSMQ. Azure Service Bus is better because: 1) No Memory Locks, 2) Dead-Lettering, 3) Scaling. Namespaces in C#:          Azure.Messaging.ServiceBus (latest)        Microsoft.Azure.ServiceBus (legacy - as of 30 Sep 2026) Basically you will be doing the typical pub/sub that is decoupled. Events should be immutable (so "record" type). Advantages: Loose Coupling, High Scalability, Real-time Responsiveness Challenges: Eventual Consistency, Debugging Is Hard, Payload Overhead Azure Service Bus is primarily a Broker topology (rather than a mediator). Steps:     1) E vent:  public record OrderPlacedEvent(Guid OrderId, string CustomerEmail, decimal TotalAmount);           2) Producer (Publishes to Azure Topic) : using System.Text.Json; using Azure.Messaging.ServiceBus; public class AzureEventPublisher {     private readonly ServiceBusSender _sender;     ...

C# Proposal

 https://github.com/dotnet/csharplang/discussions/10306

What does AI mean for sr. devs?

What does AI mean  for senior developers?    So routine or tactical programming will die. We now have AI which is a multiplier for a senior developer. So senior developers will need to focus on strategic programming. STRATEGIC PROGRAMMING  * Work on wisdom by experience.  * Looking at overall goal.  * Design hard parts up front.  * Tasks well scoped  * Interfaces between modules  * Test seams  * Design code base is clean and where can find what you want. Overall, you need to get good at your domain.

Context Engineering In AI

Image
Context Engineering In AI  * Overall, we need to compact the context to stay in AI's smart zone which is usually under 40% of the official max context.    * Remember that there are always system instructions, Claude.md, Built-In Tools, and MCP Tools that take space in the context. Next there is always the prompt and the subagents that locate and analyze the code base.    * So you need to create research.md for the PR with the remaining space of 300 to 1000 lines.  These lines include your organization's rules, your team rules, which specific repo, which specific products, which specific modules, which specific directories, and which specific code.  * Next need to create plan to fix ( plan.md ) for the PR. This needs to be the combination of the research.md plus the PRD/ticket/bug report. This plan.md ideally will be 300 to 1000 lines.  * You need to have a human review of the research.md and plan.md as the process goe...

Testing AI Coding

Testing AI Coding Testing AI-generated code:  * Shift from a "code review" mindset to an aggressive "runtime verification" strategy.  * Never let the same AI model write both the source code and the unit tests. Checklist: * Property Tests: Run randomized data to verify edge cases. * Input Validation: Check nulls, empty strings, and malformed JSON. * Dependency Audit: Pin explicit versions to flag stale training data. * PR Tagging: Label code as [AI-Generated] to alert reviewers. * Runtime Verification: Spin up ephemeral environments to observe actual execution behavior. Tools:  * Ito:   R uns your app, before reviewing the code. Uses Github PR. Attaches product demo video to PR.  https://www.ito.ai/  * Autonoma:  Self-updating UI testing. https://getautonoma.com/  * Testkube: CI against live infrastructure. Cloud-native. https://testkube.io/