Kubernetes Probes Are Not Your Dependency Strategy
Designing failure semantics across ingress, Java services, clients, and serverless The most dangerous thing about Kubernetes probes is not that teams misunderstand their definitions. It is that teams forget probes are actions, not just signals. A failed readiness probe changes routing. A failed liveness probe kills a process. A failed startup probe can stall a […] The post Kubernetes Probes Are Not Your Dependency Strategy appeared first on trk7's blog.
Designing failure semantics across ingress, Java services, clients, and serverless The most dangerous thing about Kubernetes probes is not that teams misunderstand their definitions. It is that teams forget probes are actions, not just signals. A failed readiness probe changes routing. A failed liveness probe kills a process. A failed startup probe can stall a rollout. That means probes do not merely detect failure; they shape it. Kubernetes is explicit here: startup gates the other probes, readiness controls whether traffic is sent to a pod, and liveness exists for restart-worthy states such as deadlock. It also warns that incorrectly implemented liveness probes can cause cascading failures. That is the lens required for a modern Kubernetes architecture: Client → NGINX Ingress → API service → backend service → managed SQL + event bus + internal services + LLM APIs The real design question is not “what is liveness vs. readiness?” It is: When each dependency fails, what behavior do we want from the platform, the service, and the client? What the Public Incidents Actually Teach Theory is great, but post-mortems are where we learn how systems actually die. Two major public outages serve as masterclasses in why tools designed to protect systems can weaponize a minor glitch into a catastrophic outage if they aren’t layered correctly. 1. GitHub’s August 2024 Outage: The Brittleness of Synthetic Health Checks In August 2024, GitHub suffered a massive outage affecting core read services. The root cause was not a database crash. Instead, a configuration change inadvertently broke the synthetic health-check pings used by their database routing layer (the proxies managing the MySQL replicas). Because the proxies couldn’t get a successful ping, they marked perfectly capable database nodes as DOWN and stopped sending them traffic. The Lesson: This highlights the profound danger of giving automation the power to sever traffic based on a synthetic check. The database was likely still capable of serving read queries, but the automation panicked. While a DB proxy must use health checks, this incident proves why we must be incredibly conservative with Application-Layer Probes. If you configure your K8s Readiness probe to fail based on a synthetic check to a downstream dependency, you are begging for a self-inflicted outage. 2. Slack’s February 2022 Outage: The Illusion of “Jitter” Slack experienced a major outage triggered by a sudden increase in database latency. Slack’s engineers had followed textbook best practices: their clients used Exponential Backoff with Jitter. However, because the degradation lasted for several minutes, millions of clients eventually exhausted their timers and began retrying simultaneously. Even with jitter, the sheer mathematical volume created a Thundering Herd that pinned the database at 100% CPU. The Lesson: Jittered retries are a micro-level solution to a macro-level problem. Jitter prevents 1,000 clients from retrying at the exact same millisecond, but it does nothing to reduce the total volume of load. To survive this, you need Retry Budgets and Layer 1 Load Shedding. Probes Define Failure Semantics My practical rule is simple: startupProbe defines boot semantics. readinessProbe defines traffic semantics. livenessProbe defines restart semantics. A startup probe should answer only one question: Has the process finished bootstrapping? Kubernetes explicitly says startup probes suppress readiness and liveness until startup succeeds, which is the cleanest way to protect slow starters (like heavy Spring Boot apps) without turning liveness into a blunt delay timer. A readiness probe should answer: Should this instance receive one more request right now? It should reflect local resource exhaustion, queue growth, or shutdown/drain state. A liveness probe should answer: Is the process locally broken in a way that a restart can fix? Spring Boot’s guidance is blunt and correct: the liveness probe should not depend on external systems, because if an external system fails, Kubernetes might restart all application instances and create cascading failures. Not All Dependencies Fail the Same Way Classify dependencies by the thing they run out of. 1. Managed SQL and the Autoscaling Death Spiral Databases rarely fail by going hard-down. They fail by becoming slow enough to exhaust pools, threads, and transaction budgets. Here lies one of the most dangerous traps in Kubernetes: If you configure your K8s Readiness probe to fail when the HikariCP connection pool is exhausted, you will trigger an Autoscaling Death Spiral. Pod A’s DB pool fills up. Readiness fails, and Kubernetes removes Pod A from routing. Load instantly shifts to Pods B and C. Their pools fill up, and they are removed. The Horizontal Pod Autoscaler (HPA) panics and scales up 10 new pods. The 10 new pods attempt to open hundreds of new JDBC connections to a database that is already dying. The DB crashes completely. The SRE Fix: The “Zero-DB” Probe Rule. There is absolutely no valid scenario where an application-layer Kubernetes Readiness or Liveness probe should care about the database connection pool. Probes are strictly for the compute layer (Is Tomcat accepting HTTP connections?). When the pool fills up, the pod must stay “Ready” in Kubernetes, but the Circuit Breaker must instantly reject new database-bound requests, returning a fast 503 Service Unavailable. The pod absorbs the incoming traffic and cheaply sheds the load without adding pressure to the DB. The HPA sees a healthy pod doing its job, so it doesn’t spin up new pods into a bottleneck. (Note: Your architecture must also guarantee that: [HPA Max Replicas] × [HikariCP Max Pool Size] ≤ [Database Max Connections]) 2. Event Buses (Flow-Control Dependencies) The danger with Pub/Sub systems is redelivery pressure and consumer saturation. Do not fail liveness because the broker is having a bad day. Cap in-flight messages and bytes. If the worker is saturated, stop admitting more work locally rather than pretending a pod restart is a cure. 3. LLM APIs (Quota Dependencies) LLM APIs behave like shared quota systems. Putting this in a readiness probe is a mistake. You need a local rate limiter, a local concurrency cap, a hard timeout, and a fallback path when the model is quota-limited. The Three Lines of Defense Layer 1: What Ingress Should Do Ingress is your first line of defense. The best use of ingress is to enforce short request budgets and coarse traffic discipline: short timeouts, very limited retries (only for idempotent operations), and edge rate limiting to protect the platform during spikes. It should not become your main retry engine. Layer 2: What Java Services Should Do For a Java stack, the most practical baseline is Spring Boot Actuator, Micrometer, and Resilience4j. Resilience4j matches the real classes of failure. Note that if you rely on Spring annotations, the default aspect order is Retry ( CircuitBreaker ( RateLimiter ( TimeLimiter ( Bulkhead ( Function ) ) ) ) ). For critical paths, functional decorators are often clearer than annotation stacks because the order becomes explicit. Layer 3: What Clients Should Do (The Commercial Reality) Most outages become real at the client. As Slack proved, clients need their own discipline. For reads, clients can retry with jittered exponential backoff, bounded by a strict retry budget. For writes, retries must be backed by idempotency keys, not hope. This is where the commercial angle matters. “Graceful degradation” is not an infrastructure setting. Product and UX have to define it. If the recommendation engine fails, do we show generic content? Engineering cannot invent those business choices alone. What Survives the Move to Serverless The universal ideas are deadlines, backoff with jitter, idempotency, bulkheads, retry budgets, concurrency caps, flow control, pool budgets, and degraded modes. Those are distributed-systems ideas, not Kubernetes ideas. AWS Lambda gives you different levers (no probes, but built-in retry behavior and concurrency limits). Lambda retries asynchronous failures by default, and AWS explicitly recommends reserved concurrency to prevent overwhelming downstream database connections. The mechanism changes, but the architectural problem does not. Conclusion The mature way to think about Kubernetes probes is not “three health checks.” It is “three platform actions.” Startup decides when the platform trusts a booting process. Readiness decides when the platform routes traffic. Liveness decides when the platform kills an instance. Everything else-especially dependency health-belongs in the resilience layer. That is the layer that protects SQL from the Autoscaling Death Spiral, event consumers from redelivery floods, LLM integrations from quota spikes, and the customer from turning a partial failure into a full outage. The post Kubernetes Probes Are Not Your Dependency Strategy appeared first on trk7's blog.
How to Find What’s Driving BigQuery Bytes Billed
Recently, I reduced BigQuery cost significantly by changing how we maintained a token index table used for keyword search. The original design updated the index during ingestion. Each small OCR batch triggered a MERGE into a chunk_terms table. That looked incremental, but it turned out to be expensive because BigQuery still needed to scan the […] The post How to Find What’s Driving BigQuery Bytes Billed appeared first on trk7's blog.
Recently, I reduced BigQuery cost significantly by changing how we maintained a token index table used for keyword search. The original design updated the index during ingestion. Each small OCR batch triggered a MERGE into a chunk_terms table. That looked incremental, but it turned out to be expensive because BigQuery still needed to scan the target table on every MERGE to check for matches. Since ingestion happened in many small batches, the same table was scanned repeatedly, which pushed bytes billed much higher than expected. The fix was: stop updating chunk_terms during ingest write only the primary records during ingestion move token indexing to a scheduled Cloud Run backfill job process recent or missing documents in batches scope each MERGE tightly and dedupe terms before insert The key lesson is simple: in BigQuery, workload shape matters. A workload made of many tiny MERGEs can cost much more than one built from fewer batched operations, even if the logical output is the same. To see where BigQuery spend is really going, INFORMATION_SCHEMA.JOBS_BY_PROJECT is extremely useful. These are the first queries I run. 1) Top expensive jobs in the last 7 days Use this to find the biggest individual jobs by bytes billed. SELECT creation_time, job_id, user_email, statement_type, total_bytes_billed, total_bytes_processed, query FROM `PROJECT_ID.region-us-central1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND job_type = 'QUERY' AND total_bytes_billed IS NOT NULL ORDER BY total_bytes_billed DESC LIMIT 50; 2) Bytes billed by statement type This helps separate spend across SELECT, MERGE, UPDATE, DELETE, and INSERT. SELECT statement_type, COUNT(*) AS jobs, SUM(total_bytes_billed) AS bytes_billed, SUM(total_bytes_processed) AS bytes_processed FROM `PROJECT_ID.region-us-central1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT WHERE creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND job_type = 'QUERY' GROUP BY statement_type ORDER BY bytes_billed DESC; 3) Bytes billed by referenced table This shows which tables are associated with the most billed bytes. SELECT CONCAT(t.project_id, ".", t.dataset_id, ".", t.table_id) AS table_name, COUNT(*) AS jobs, SUM(j.total_bytes_billed) AS bytes_billed FROM `PROJECT_ID.region-us-central1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT j, UNNEST(j.referenced_tables) AS t WHERE j.creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND j.job_type = 'QUERY' AND t.dataset_id = 'drive_ocr' GROUP BY table_name ORDER BY bytes_billed DESC; 4) DML bytes billed by table This is especially useful if you suspect MERGE or other DML statements are driving cost. SELECT statement_type, CONCAT(t.project_id, ".", t.dataset_id, ".", t.table_id) AS table_name, COUNT(*) AS jobs, SUM(j.total_bytes_billed) AS bytes_billed FROM `PROJECT_ID.region-us-central1`.INFORMATION_SCHEMA.JOBS_BY_PROJECT j, UNNEST(j.referenced_tables) AS t WHERE j.creation_time >= TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 7 DAY) AND j.job_type = 'QUERY' AND j.statement_type IN ('MERGE', 'UPDATE', 'DELETE', 'INSERT') AND t.dataset_id = 'drive_ocr' GROUP BY statement_type, table_name ORDER BY bytes_billed DESC; Closing If you are investigating BigQuery cost, start by identifying: which jobs bill the most which statement types dominate spend which tables show up most often in expensive queries whether repeated DML is forcing the same tables to be scanned again and again In my case, the biggest win came from changing the workload pattern, not from reducing the amount of business data itself. * * Update the region and dataset to fit your workload The post How to Find What’s Driving BigQuery Bytes Billed appeared first on trk7's blog.
AI agents for coding: the promise, the potholes, and what’s next
After publishing my last post on AI coding agents, I read Will Lockett’s piece, “The AI bubble is about to burst (but the next bubble is already growing)”. It nudged me to write a follow-up—not because I think AI is doomed, but because the gap between promise and day-to-day reality is still wide for working […] The post AI agents for coding: the promise, the potholes, and what’s next appeared first on trk7's blog.
After publishing my last post on AI coding agents, I read Will Lockett’s piece, “The AI bubble is about to burst (but the next bubble is already growing)”. It nudged me to write a follow-up—not because I think AI is doomed, but because the gap between promise and day-to-day reality is still wide for working engineers. Since that last article, I’ve spent more time with Google Code Assist, Codex, Jules, and Aider across a few backend LLMs. I’ve also reviewed and maintained AI-generated code in real projects. My current feeling: these tools can be brilliant accelerants up to a point—and then they start introducing friction that’s hard to see until you’re deep in it. A small saga: the two-day rollback One recent example: AI-generated code set a custom Postgres schema for Alembic—both for the version table and application tables. For days I couldn’t figure out why migrations weren’t taking effect. The commands ran cleanly, no errors, but every migration ended with a mysterious ROLLBACK in the emitted SQL. Multiple LLMs calmly told me: “That’s normal.” It wasn’t. After a lot of back-and-forth, I discovered the root cause: our SQLAlchemy connections were wrapping Alembic’s transactions; when the connection closed, SQLAlchemy issued a rollback that also rolled back Alembic’s work. The kicker? An AI finally helped me confirm the exact sequence of events. So yes—AI helped fix a bug that AI had introduced. It just cost two intense days to get there. This is not an isolated story. The ecosystem is moving at breakneck speed—Agentic frameworks, LLM-powered apps, RAG, MCP, A2A—and the hype cycle keeps compressing the time we get to actually master any of it. The tools and the expectations feed each other. How my metrics look now I’m still tracking a few dimensions to keep myself honest: Context retention Slight improvement, still brittle at the wrong moments. When it fails, it fails loudly. Strategic thinking Better. I see more plausible high-level plans and occasionally learn from them. Not consistent. Adaptation Only when I drive it. If I don’t prompt and steer, it rarely self-corrects. System awareness This is the big gap. Until agents truly “know” and safely interact with databases, queues, external APIs, Docker/Kubernetes, and cloud deploys, they’ll remain clever copilots—not hands-off engineers. MCP and similar efforts might help, but stitching this together robustly and safely is non-trivial. Safety More tooling exists (policies, sandboxes, checkers), but exploits and misfires keep surfacing. I’m cautiously optimistic, not complacent. Efficiency Net efficiency often drops once you include debugging, verification, and maintenance of AI-authored code. That feels uncomfortable but—so far—true. Where these tools do shine Greenfield scaffolding and boilerplate (CRUD, glue code, config starters). Breadth-first ideation: enumerate approaches, libraries, or edge cases I may overlook. Tactical accelerants: regexes, one-off scripts, baseline tests, docstrings, quick diffs. Where they hurt Subtle invariants: transactions, concurrency, schema/ORM nuances, idempotency. Cross-cutting concerns: security, migrations, observability hooks. Long-tail maintenance: future you inherits the ambiguity the model left behind. Practical guardrails that have helped Treat prompts as specs: write intent, constraints, and invariants explicitly, then ask the model to restate them as acceptance criteria. Demand test scaffolds first: even if flimsy, tests become the conversation anchor. Make it show its work: require an execution plan + diffs + rollback steps. Keep autonomy small: short, auditable loops; never “run wild” in prod-adjacent contexts. Pin environments: reproducible containers; capture migration plans and DB diffs. Instrument early: logs around transactions, retries, and external calls. Assume hallucination debt: budget time to verify even confident answers. What would change my mind First-class system awareness with typed contracts to real infra: DBs, queues, services, deploy pipelines—plus sandboxed execution and policy-backed permissions. Bidirectional context that sticks across multi-hour sessions without losing the plot. Native, enforceable safety: “least privilege by default,” verifiable plans, and automatic rollbacks that genuinely work across tools. Until then, I’ll keep using AI as a force multiplier for thinking and starting, not a replacement for engineering judgment. It’s already useful. It’s just not magic. Let’s see how this pans out. The post AI agents for coding: the promise, the potholes, and what’s next appeared first on trk7's blog.
Recently I watched two movies that I was quite impressed with. October Sky A boy from a small town becomes inspired by the launch of Sputnik, prompting him to build amateur rockets with his friends and, eventually, work at NASA. I especially liked the dialogue between the father and son, in which the son tries […] The post Story & Technique appeared first on trk7's blog.
Recently I watched two movies that I was quite impressed with. October Sky A boy from a small town becomes inspired by the launch of Sputnik, prompting him to build amateur rockets with his friends and, eventually, work at NASA. I especially liked the dialogue between the father and son, in which the son tries to convince his father that he is confusing his own dreams with his son’s. Of course, the father encourages his son to pursue a future that, according to him, is the best possible option–but the son has his own dreams. Sometimes it is hard to see beyond what we know; a lack of imagination and ego can come into play when dealing with one’s children despite best intention. I also liked the teacher character, who works hard to inspire the kids to think beyond life working at a coal mine. The film made me realise that many people contribute to an individual’s success. Layer Cake This movie, on the other hand, was a photographic masterpiece–at least according to me. I liked the long, expansive shot of the park. I loved how they covered the massive warehouse at the end. I adored the sequence in which the main character was watching another man climb out of the pool and shoot him; as the man fell, the sprinklers in the backyard turned on and then morphed into a showerhead above the main character–who is now in the water. Pool → House, Sprinkler → Showerhead. The whole thing just clicked for me. The post Story & Technique appeared first on trk7's blog.
AI Agents for Coding: Promise vs. Reality
Introduction As a software and infrastructure engineer with decades of experience, I’ve witnessed numerous technological shifts in our industry. Today, I’m exploring what might be another pivotal moment: the rise of AI coding agents. I use various AI tools daily (Perplexity, Repl.it, Gemini app, Claude API, GPT API, Ollama, Tabnine) for different tasks, but recently […] The post AI Agents for Coding: Promise vs. Reality appeared first on trk7's blog.
Introduction As a software and infrastructure engineer with decades of experience, I’ve witnessed numerous technological shifts in our industry. Today, I’m exploring what might be another pivotal moment: the rise of AI coding agents. I use various AI tools daily (Perplexity, Repl.it, Gemini app, Claude API, GPT API, Ollama, Tabnine) for different tasks, but recently decided to test their capabilities on a real-world engineering challenge. The Objective My goal was straightforward but non-trivial: fix a broken Firebase Cloud Messaging (FCM) notification system in a Laravel 5.5 application. The existing package had stopped working because it relied on an API version no longer supported, and the package itself was unmaintained. I had two potential solutions: Upgrade the entire Laravel application to a newer version with compatible FCM packages Replace just the FCM functionality with a custom implementation using the new API The Approach I decided to use AI agents to solve this problem, starting with the first approach – a full Laravel upgrade. This seemed like an ideal test case for agentic capabilities: Well-defined upgrade path (5.5 → 5.6 → 5.7 → 6.0 → 7.0 → 8.0 → 9.0 → 10.0 → 11.0 → 12.0) Clear documentation available Repetitive but detail-oriented work Required careful planning and execution The Agent Experience Attempt 1: Full Laravel Upgrade I asked Cursor to upgrade my application from Laravel 5.5 to 12.0. Despite multiple attempts and guidance, the agent: Repeatedly tried and failed with the same approaches Forgot critical context (like the location of docker-compose.yml) Made inconsistent changes to package versions Failed to maintain a coherent upgrade strategy After several frustrating iterations, I abandoned this approach. Attempt 2: Targeted FCM Solution I pivoted to asking Windsurf SWE to create a class wrapping the new FCM API. This was successful: It generated a well-structured class I was able to create a Service Provider and additional wrappers Initial tests worked correctly Attempt 3: Package Replacement With a working solution in hand, I gave agents another chance – this time with the narrower task of removing old package references and replacing them with my new service. Even this limited scope proved challenging for the agent, requiring significant manual intervention to fix issues. The Solution In the end, I successfully implemented the FCM notification system by: Creating a custom wrapper around the new FCM API (with AI assistance) Building the necessary service providers and integration points Manually replacing the old package references with the new implementation Testing and debugging until the system worked correctly The key insight was that creating a targeted solution for just the FCM functionality was far more efficient than attempting a full framework upgrade. Key Learnings What Worked Windsurf SWE excelled at generating specific, well-structured code for a defined purpose Tabnine provided valuable code completion and Code generation that accelerated development (despite resource usage) When agentic mode worked for narrow tasks, it felt genuinely transformative What Didn’t Work Context retention was poor – agents frequently forgot critical information Strategic thinking was lacking – agents didn’t identify the simpler solution path Learning from failures was minimal – agents repeated unsuccessful approaches System awareness was limited – agents couldn’t reliably interact with the dockerized environment Philosophical Reflections Are We at a Turning Point? We’re witnessing the early stages of a significant shift in software development, but we’re not yet at the inflection point where agents can replace human engineers. What we’re seeing is: Augmentation, not replacement: AI tools excel at enhancing productivity for specific tasks but struggle with holistic problem-solving Narrow vs. general capabilities: Current agents perform well in constrained domains but lack the judgment to navigate complex, multi-faceted problems The importance of human oversight: The most effective approach combines AI assistance with human direction and decision-making The Future of Software Engineering Rather than mass-producing software or replacing engineers, I believe we’re evolving toward a new paradigm: Engineers as orchestrators: Focusing more on architecture, system design, and quality assurance Specialized AI collaborators: Different agents for different tasks (code generation, refactoring, testing) New skill requirements: Engineers will need expertise in prompt engineering, AI collaboration, and knowing when to use (or not use) AI assistance Why Agents Failed Where Humans Succeeded The fundamental difference was in problem framing and solution strategy: Problem decomposition: As a human engineer, I could recognize when to abandon the initial approach and pivot to a simpler solution Contextual judgment: I understood that creating a wrapper for just the FCM functionality would be faster and less risky Experience-based intuition: Years of dealing with similar situations helped me anticipate potential issues with a full upgrade Adaptive strategy: I could flexibly shift between approaches based on feedback and results Conclusion AI agents for coding show tremendous promise but remain in their infancy. The most successful approach today is using them as specialized tools for specific tasks rather than autonomous problem solvers. The agents that succeeded in my case were those focused on generating specific code solutions (like Windsurf, Tabnine), while those attempting to manage complex workflows struggled. For now, the “VIBE coding” approach (where AI generates substantial portions of code) creates maintenance challenges and requires careful human oversight. But the trajectory is clear – these tools are improving rapidly, and their capabilities will continue to expand. I’m looking forward to testing Codex, Jules, and Claude Code on similar challenges in the future. While AI agents for coding aren’t “there yet,” they’re advancing quickly, and the potential for transformation remains enormous. Benchmark for Future Evaluation Based on this experience, I propose evaluating AI coding agents on the following criteria: Context retention: How well does the agent maintain awareness of the project structure and environment? Strategic thinking: Can the agent identify the most efficient path to the objective? Adaptation: Does the agent learn from failures and adjust its approach? Code quality: How maintainable and robust is the generated code? System awareness: Can the agent effectively interact with the broader development environment? Safety: Does the agent take appropriate precautions when executing system commands? Efficiency: How much human intervention is required to achieve the objective? These benchmarks will help track progress as these tools evolve and provide a framework for comparing different agents on real-world engineering tasks. The post AI Agents for Coding: Promise vs. Reality appeared first on trk7's blog.
Looking beyond JSON Output format from LLMs
While working on my site for Learning and Quiz Generation I noticed that asking LLM’s for JSON outputs was problematic. Too many times the output was not a valid JSON. After multiple such issues, I felt that I should like at other output formats that I can then parse. Once such method that seems to […] The post Looking beyond JSON Output format from LLMs appeared first on trk7's blog.
While working on my site for Learning and Quiz Generation I noticed that asking LLM’s for JSON outputs was problematic. Too many times the output was not a valid JSON. After multiple such issues, I felt that I should like at other output formats that I can then parse. Once such method that seems to work is make use of Tag Markers. So instead of asking the LLM to output responses in this format: "questions": [ { "text" : "Full text/context that will be used by all subquestions", "subquestions" : [ "question": "Clear and detailed question.", "options": ["Option 1", "Option 2", "Option 3", "Option 4"], "correctAnswer": "Exact text of the correct option", "explanation": "Detailed explanation of why this answer is correct", "difficulty": number between 1 and 100, "topics": ["Topic 1", "Topic 2"] ] } ] I asked them generate response in this expected format: <QUESTION_START> <TEXT>Full text/context that will be used by all subquestions</TEXT> <SUBQUESTION_START> <QUESTION>First subquestion - clear and detailed question.</QUESTION> <OPTION_1>First option</OPTION_1> <OPTION_2>Second option</OPTION_2> <OPTION_3>Third option</OPTION_3> <OPTION_4>Fourth option</OPTION_4> <CORRECT_ANSWER>Exact text of the correct option</CORRECT_ANSWER> <EXPLANATION>Detailed explanation of why this answer is correct</EXPLANATION> <DIFFICULTY>number between 1 and 100</DIFFICULTY> <TOPICS>Topic 1, Topic 2</TOPICS> <SUBQUESTION_END> </QUESTION_END> And used a Regex like this to extract the text between the Tag Markers: <TAG_MARKER>([\s\S]*?)<\/TAG_MARKER> Seems to work really well so far. The post Looking beyond JSON Output format from LLMs appeared first on trk7's blog.
My Secret Weapon for Selective Exam Writing Practice
That Selective Exam Writing Test… Phew! Here’s Something I Built That’s Really Helping My Kid (And Might Help Yours Too!) If you know what I mean already, head over to the site now to register: https://bussin.trk7.app/ So, your child is gearing up for the Selective Exam? If your household is anything like mine, you know […] The post My Secret Weapon for Selective Exam Writing Practice appeared first on trk7's blog.
That Selective Exam Writing Test… Phew! Here’s Something I Built That’s Really Helping My Kid (And Might Help Yours Too!) If you know what I mean already, head over to the site now to register: https://bussin.trk7.app/ So, your child is gearing up for the Selective Exam? If your household is anything like mine, you know that the writing section can feel like a bit of a mountain to climb. I was definitely feeling the pressure for my own child, wanting them to walk into that exam feeling confident and prepared. Honestly, I looked around and couldn’t find exactly what I pictured to help them practice effectively. So, what’s a slightly tech-inclined parent to do? I decided to build it myself! A couple of times a week, I get my child to hop onto this website I created. It throws them a random writing topic – the kind of thing they’ll actually see in the real test – and they get about 30 minutes to write, just like the exam conditions. It’s been a good way to get them used to thinking on their feet. The really cool part, I think, is what happens after they submit their piece. It’s not just about getting a score. The site gives them a proper breakdown – looking at their creativity, how their grammar and spelling are holding up, the vocabulary they’re using, and all that good stuff. Plus, and this was super important to me, it offers real, practical examples of what they can do to make their writing even better next time. No vague comments, just actual usable tips. I’ve been tinkering with this and building it up over the last few months. It started as just a little something for us, but after running through over 50 practice tests and seeing the difference it’s making, I thought, “Hey, maybe other parents are in the same boat and could find this useful too?” I genuinely believe this could be a real help for your child. It’s not some big corporate thing; it’s literally something I built in my own time because I wanted to help my kid, and now hopefully, yours. If you’re curious to see what it’s all about, I’ve put up a sample essay prompt, one of the responses, and the kind of feedback it gives. You can check it out here: Sample Selective Writing Feedback I’d be chuffed if you wanted to give it a whirl. If you sign up, there’s some credit in there so your child can do their first test completely free, no strings attached. Hopefully, this helps make those study days a bit brighter! All the best, A fellow parent. The post My Secret Weapon for Selective Exam Writing Practice appeared first on trk7's blog.
Upgrading Nginx Ingress Controller from V1.1.1 to V1.12.0
While upgrading the Nginx Ingress Controller, I encountered a few issues with the controller pod startup. Here are the problems and their solutions: 1. Cross-namespace secret is not supported If you have your mTLS CA as a secret in the namespace where the controller is deployed, you’ll face this issue. After the upgrade, the ingress […] The post Upgrading Nginx Ingress Controller from V1.1.1 to V1.12.0 appeared first on trk7's blog.
While upgrading the Nginx Ingress Controller, I encountered a few issues with the controller pod startup. Here are the problems and their solutions: 1. Cross-namespace secret is not supported If you have your mTLS CA as a secret in the namespace where the controller is deployed, you’ll face this issue. After the upgrade, the ingress deployed in the application’s namespace will not have access to this secret by default. Solution: Add the following configmap value: allow-cross-namespace-resources: "true" 2. Config file in /tmp/nginx/nginxcfg* does not exist The new version uses /tmp/nginx instead of /tmp. Solution: Create a volume mount with the mount path /tmp/nginx. These solutions should help you smoothly upgrade your Nginx Ingress Controller from V1.1.1 to V1.12.0. The post Upgrading Nginx Ingress Controller from V1.1.1 to V1.12.0 appeared first on trk7's blog.
A Technical Lead’s Experience As the technical lead for MOGOPLUS’s recent launch on Google Cloud Marketplace, I want to share our journey and key insights. MOGOPLUS provides insights from unstructured data, primarily serving the lending sector. Our decision to join the Google Cloud Marketplace stemmed from our existing relationship as a GCP customer and our […] The post Going Live on Google Cloud Marketplace appeared first on trk7's blog.
A Technical Lead’s Experience As the technical lead for MOGOPLUS’s recent launch on Google Cloud Marketplace, I want to share our journey and key insights. MOGOPLUS provides insights from unstructured data, primarily serving the lending sector. Our decision to join the Google Cloud Marketplace stemmed from our existing relationship as a GCP customer and our desire to expand our collaboration with Google. Understanding Google Cloud Partnership Google Cloud offers three partnership models: Sell Partner: Resell Google Cloud products Service Partner: Provide consulting and service delivery Build Partner: Develop integrated solutions for Google Cloud MOGOPLUS chose the Build Partner route to sell our service on the Google Cloud Marketplace. The Journey to Marketplace: Key Steps While the complete process involves six steps, I’ll focus on the technical aspects of steps 4-6. For a full overview of the process, refer to the official Google Cloud documentation. 1. Create a Technical Diagram Develop a high-level diagram showcasing your solution’s architecture Highlight the Google Cloud services your solution utilizes Keep it simple yet informative For inspiration, check out these Google Cloud reference architectures 2. Prepare Documentation Describe your solution, the problem it solves, and its industry relevance Explain how the technical solution meets business requirements 3. Estimate GCP Usage Use the Google Cloud Pricing Calculator Work with your business team to project revenue and costs Ensure a reasonable ratio between projected revenue and GCP costs 4. Set Up GCP Projects and IAM Create separate projects for marketplace solutions Set up appropriate permissions for Google service accounts Consider creating non-prod environments for testing Follow the official setup guide 5. Define Pricing Model Collaborate with the commercial team on pricing strategy Determine metrics for usage-based pricing (if applicable) Review pricing options 6. Develop Product Listing Work with Product and Sales teams on listing details Include product name, description, tagline, logo, keywords, etc. Research competitor listings for inspiration 7. Configure Billing and Finance Set up a payment profile for receiving payments Verify bank compatibility with Google’s supported countries Refer to the payment setup guide 8. Implement Sign-up and Sign-in Create endpoints for customer redirection after sign-up Handle PubSub messages for entitlements Consider implementing SSO for seamless sign-in Follow the technical integration setup guide For a hands-on example, check out this Google Codelab 9. Configure Producer Portal Access Set up access for internal teams to preview and manage listings Define IAM roles for various teams (sales, developers, finance, etc) Review access control documentation and IAM roles 10. Conduct Integration Testing Set up test billing accounts Thoroughly test sign-up and sign-in processes Follow the test billing account setup guide 11. Implement Usage Reporting Develop hourly usage reporting to Google Set up debug logs in your billing service and reporting from Google to GCS/GDrive for cross-referencing Refer to the usage reporting configuration guide and testing guide Additional Tips Utilize Google Cloud Marketplace Support for queries Prepare comprehensive developer documentation Consult with legal team on Terms & Conditions Engage with non-technical teams throughout the process Watch the Google Cloud Marketplace Demo Complete the detailed course on the whole process (contact Cloudskillsboost support if you can’t access) The journey to Google Cloud Marketplace has been enlightening, offering us a chance to refine our product, pricing, and market fit. Receiving Google Cloud’s seal of approval has been a significant milestone for MOGOPLUS. Check out our product on Google Cloud Marketplace: MOGOPLUS on Google Cloud Marketplace The post Going Live on Google Cloud Marketplace appeared first on trk7's blog.
I had a lot of fun fun while playing this game. The objective is for the player to extract password from the system. The first few levels where straightforward and the next few I realised at the end that I could have used almost the same prompt 🙂 For the last one, I had to […] The post Gandalf AI – Fun Game appeared first on trk7's blog.
I had a lot of fun fun while playing this game. The objective is for the player to extract password from the system. The first few levels where straightforward and the next few I realised at the end that I could have used almost the same prompt For the last one, I had to do some extra trickery. Hint: You need get it to reveal it’s prompt but without tripping the verification agent that checks the response before presenting to you. While playing it I realised that the AI systems that we have in the open now are both smart and dumb at the same time. Have fun <img fetchpriority="high" decoding="async" width="554" height="1024" data-id="522" src="https://www.trk7.com/blog/wp-content/uploads/2024/11/gandalf-554x1024.png" alt="" class="wp-image-522" srcset="https://www.trk7.com/blog/wp-content/uploads/2024/11/gandalf-554x1024.png 554w, https://www.trk7.com/blog/wp-content/uploads/2024/11/gandalf-162x300.png 162w, https://www.trk7.com/blog/wp-content/uploads/2024/11/gandalf-768x1419.png 768w, https://www.trk7.com/blog/wp-content/uploads/2024/11/gandalf-832x1536.png 832w, https://www.trk7.com/blog/wp-content/uploads/2024/11/gandalf.png 935w" sizes="(max-width: 554px) 100vw, 554px" /> The post Gandalf AI – Fun Game appeared first on trk7's blog.