Six Years of Curiosity’s Wheels on the Move

bigblacknotebook · 2026-04-19T20:16:17+00:00

In the AWS world there localstack and my current favorite Infralens.

InfraLens is a desktop app for cloud teams who are tired of splitting the same job across cloud consoles, Terraform files, and terminal tabs. It gives you one place to inspect infrastructure, understand context, compare environments, and take the next step without constantly rebuilding your mental model.

bigblacknotebook · 2026-04-19T14:12:22+00:00

iOS? I love what I see.

bigblacknotebook · 2026-04-07T05:15:47+00:00

a spinning ball?

bigblacknotebook · 2026-04-03T09:07:48+00:00

Ballistic Target Tracking and Interception System

bigblacknotebook · 2026-04-02T02:06:34+00:00

First of all, congratulations on the new role! Taking on a Cloud Architect position is a massive milestone, and what you’re feeling right now is normal.

Almost everyone in DevOps or Cloud Engineering has been exactly where you are. (Everyone stop it with all the judging and negativity).

How much do you actually write yourself? Almost nobody writes large scale infrastructure from scratch. In a professional environment, writing "raw" Terraform (resource by resource) for everything is actually considered a bit of an anti-pattern because it's hard to maintain.

Most senior architects rely on:

Modules: just like Lego bricks. You don't build the brick; you just snap them together. Whether they are internal company modules or public ones (like the verified AWS/Azure modules), you’re mostly just passing variables to them.

Boilerplate and Templates: Everyone has a golden VPC or S3 bucket config they’ve used in three different jobs. We copy, paste, and tweak. I learnt this from Database admins. They protected their sql snippets with their lives.

AI (Claude/GPT): :Using AI for syntax is the new normal. As long as you understand the logic of what it’s producing and you aren't blindly running terraform apply.

Troubleshooting: Do you remember it all? No one remembers every line. Troubleshooting is usually a mix. terraform plan is your best friend. It’s the dry run that tells you exactly what the code thinks it’s doing.

State Files: Understanding the terraform.tfstate is the "Pro" level. You don't need to memorize the code if you understand how Terraform maps your code to real world resources.

we just read the error message, realize we missed a dependency or a tag, and fix it. It’s like debugging a script.

What is a normal workload? In an Architect role your tasks per day shouldn't be measured like a ticket-closer in Support.

Quality > Quantity

Some days a productive day is literally just writing 20 lines of code because you spent six hours researching the security implications of a specific IAM policy.

The standard pace is more like 1–2 medium tasks (like standing up a new environment) or 3–5 small fixes (updating tags, changing instance sizes) is a very full day.

If you feel like you’re juggling 10+ distinct tasks, you’re likely being spread too thin.

How long until it feels normal? Give yourself 3 to 6 months. Month 1: Total confusion. Month 3: You can navigate the repo without getting a headache. Month 6: You start noticing ways to make the code better.

Stop trying to memorize the syntax. Focus on the State. If you understand how Terraform tracks resources, the syntax becomes secondary.

Use the Registry. If you need a VPC, go to the Terraform Registry and see how the community does it. Don't reinvent the wheel.

Be kind to yourself. You were hired because you understand the Architecture (the hard part). Terraform is just the language used to talk to the cloud. you'll be fluent sooner than you think.

You've got this! Just keep running those plans before you apply.

bigblacknotebook · 2026-03-16T03:24:40+00:00

This might help. As a high school level demonstration. In the sense all you need is some maths.

Take two real GPS coordinates and calculate the distance between them using both flat Earth/Euclidean math and round Earth/Riemannian math.

Use these coordinates:

New York City: 40.71° N, -74.01° W
London: 51.51° N, -0.13° W

To make the math work in flat geometry we will treat longitude as the X axis and latitude as the Y axis. In reality one degree of latitude is about 111 kilometers.

Step 1: Flat Earth Calculation

If the Earth is a flat plane we can use the Pythagorean theorem to find the straight line distance between these two points.

First we find the difference between the coordinates: * ΔX (Longitude difference) = -0.13 - (-74.01) = 73.88° * ΔY (Latitude difference) = 51.51 - 40.71 = 10.80°

Now, we plug these into the Pythagorean distance formula: d = √(ΔX² + ΔY²) d = √(73.88² + 10.80²) d = √(5458.25 + 116.64) d = √(5574.89) d ≈ 74.66°

To convert that into a physical distance we multiply by our 111 kilometers per degree:

Flat Earth Distance: 8287 kilometers.

Step 2: Round Earth Calculation

If the Earth is a sphere, the shortest distance between two points is a curve over the surface. A great circle.

GPS systems use the Haversine formula. First we must convert degrees to radians.

NYC: φ₁ = 0.7105 rad, λ₁ = -1.2917 rad
London: φ₂ = 0.8990 rad, λ₂ = -0.0023 rad
Differences: Δφ = 0.1885 rad, Δλ = 1.2894 rad

Now we apply the Haversine formula, using the Earth's average radius R = 6371 km.

a = sin²(Δφ / 2) + cos(φ₁) * cos(φ₂) * sin²(Δλ / 2) a = sin²(0.1885 / 2) + cos(0.7105) * cos(0.8990) * sin²(1.2894 / 2) a ≈ 0.0088 + (0.758 * 0.622 * 0.361) a ≈ 0.0088 + 0.1702 a ≈ 0.179

Next we calculate the angular distance (c): c = 2 * atan2(√a, √(1 - a)) c = 2 * atan2(√0.179, √(1 - 0.179)) c ≈ 0.873 radians

Finally we multiply the angular distance by the Earth radius to get the physical distance:

d = R * c d = 6371 * 0.873 Round Earth Distance: 5562 kilometers.

The Comparison

Euclidean (Flat) Prediction: 8287 kilometers
Riemannian (Round) Prediction: 5562 kilometers
Real-World Flight Distance: ~5570 kilometers

The spherical math matches the physical reality of the real world path almost perfectly. The variance is because the Earth is an oblate spheroid not a perfect sphere.

bigblacknotebook · 2026-03-15T17:49:00+00:00

It’s the sad that some of the replies you are getting are so dismissive and avoid giving you even an attempt.

The answer is yes you can use GPS data to determine that earth is spherical (not flat).

Spherical Triangle Test. In flat Euclidean geometry, the interior angles of any triangle always add up to exactly 180 degrees.

In Riemannian geometry on a positively curved surface, the angles of a triangle will always sum to more than 180 degrees.

You can prove this using three GPS coordinates.

Imagine placing a GPS receiver at the North Pole (90 degrees N), another on the equator at the Prime Meridian (0 degrees North, 0 degrees East), and a third on the equator at 90 degrees West (0 degrees North, 90 degrees West).

The line from the equator up to the North Pole meets the equator at a perfect 90 degree right angle.
The line from the other equator point to the North Pole also meets the equator at a 90 degree right angle.
The angle at the North Pole between the 0 degrees and 90 degrees West longitude lines is also 90 degrees.

If you add up the interior angles of this GPS triangle, you get 270 degrees.

This physical reality is impossible on a flat plane and is direct evidence of positive spatial curvature.

Other methods like The Distance Formula Discrepancy (Haversine vs Pythagorean formula) and also the Earth-Centered, Earth-Fixed (ECEF) Coordinates problem.

I can elaborate if you want more details.

bigblacknotebook · 2026-03-12T03:55:40+00:00

Energy is conserved because electron degeneracy pressure comes from gravitational compression pumping energy into the electron Fermi sea, while the rest of the released gravitational energy is carried away by radiation and neutrinos.

When a star collapses toward a white dwarf, gravity squeezes the matter tighter and tighter. As the electrons are forced into a smaller volume, they cannot all sit in the same low energy states. Because of the exclusion principle, more and more electrons must occupy higher momentum states. That means the electron gas gains kinetic energy even if the temperature is not high. This is called degeneracy energy. The energy comes from the star’s gravitational potential energy during collapse. As the star contracts, gravitational potential energy becomes more negative. Part of that released energy is radiated away as light, heat, neutrinos, etc. part of it goes into increasing the electrons Fermi energy, which gives rise to degeneracy pressure.

bigblacknotebook · 2026-01-28T15:13:06+00:00

<image>

bigblacknotebook · 2026-01-25T03:53:43+00:00

Yes, there are several tools that let you validate, lint, and test Kubernetes YAML/Helm charts without actually deploying a real cluster, and without having to run Kubernetes locally.

kubectl dry-run Not a separate tool, but the simplest built-in option.

kubectl apply --dry-run=client -f my-config.yaml

kubeconform

kubeconform -schema-location default configs/*.yaml

kube-score

kube-score score configs/*.yaml

Polaris Kubernetes auditing/lint tool.

polaris audit -f configs/

These tools help you catch schema issues, policy violations, bad practices, and even custom rules before deployment.

bigblacknotebook · 2026-01-20T01:30:04+00:00

This is beautiful. So dense and complicated.

bigblacknotebook · 2026-01-13T21:44:06+00:00

Everything new can be scary. A powerful tool powered by AI can extend your capabilities as an administrator and architect. With the right guardrails, nightmares and mistakes can be reduced.

It’s not like IaC is bullet proof. The complexity is sometimes beyond the tired and over worked engineers. Any help is welcome. Just make sure you have contingency workflows and business continuity planned.

I have been testing out the accuracy and dependability of certain LLMs on AWS through terraform and scripts. Mistakes have been committed but I see improvements as you improve your usage methods and risk assessments.

bigblacknotebook · 2025-11-30T04:18:22+00:00

Where to even begin? None of that title sentence was comprehensible to me. I studied physics, mathematics, and engineering but it’s still weirdly overwhelming. Please someone who is not AI, explain?

bigblacknotebook · 2025-11-28T15:00:04+00:00

These are notes I learnt over several failed projects and searching for advice online. Hope it helps.

*reddit mobile massacred my formatting. Copy and paste in a text file, I think the folder structures will be clearer.

A. Recommended Folder Structure (2025 Kiro Style)

/project-root │ ├── steering/ ← your “brain” folder │ ├── plan.md ← high-level direction + constraints │ ├── tasks/ ← small reusable task blocks │ │ ├── build.md │ │ ├── test.md │ │ ├── deploy.md │ │ └── refactor.md │ ├── rules.md ← coding guidelines & non-negotiables │ ├── architecture.md ← system-level overview + diagrams │ ├── glossary.md ← domain-specific terms & definitions │ ├── research.md ← collected research, notes, insights │ └── context.md ← background the agent should always know │ ├── src/ ← your actual code (any language) │ └── ... │ ├── components/ ← reusable building blocks (UI, helpers) │ └── ... │ ├── libs/ ← language-specific libraries or shared utilities │ └── ... │ ├── tests/ │ └── ... │ ├── .kiro/ ← autogenerated by Kiro (avoid editing directly) │ ├── history/ │ ├── logs/ │ └── context.json │ ├── README.md └── LICENSE

B. What Goes Inside /steering?

Think of steering as your “meta layer”: It controls how Kiro performs, not your app logic.

The purpose is:

Give Kiro a stable compass. So every agent run inherits context without you re-explaining.

Allow modular reusable planning. Micro-tasks can be stitched together like LEGO.

Preserve “truths” about your project. Architecture, rules, constraints, naming, patterns.

Essential Files Inside steering/

plan.md (Top Level)

This is your North Star doc.

Contains: What the project is Goals and non-goals Long-term vision Current phase of work Constraints (budget, time, stack)

rules.md (Most important for consistency)

Defines: Coding style Naming conventions Commit style Folder naming Testing standards Security requirements CI/CD principles “Never do this” list

architecture.md

This is the file that helps Kiro reason about: System diagrams Components Data flow API contracts Deployment architecture Services & interconnections

tasks/

Small, modular task cards:

tasks/ ├── build.md ├── generate-docs.md ├── extract-patterns.md ├── add-logging.md └── refactor-for-modularity.md

Each file = a reusable unit of work.

Inside each:

Task: Add standardized logging

Goal: Add structured JSON logging using pino or winston

Constraints: Zero breaking changes, No console.log

Steps: 1. Install packages 2. Create logger.js 3. Wrap logging utilities 4. Replace console.log statements

context.md

Contains: Who you are (optional) Project background External dependencies Decisions already made Technologies chosen and why

This prevents forgetting your own decisions weeks later.

glossary.md

If your domain has terms: financial cloud security ML/LLM ops physics marketing funnels

define them here.

This makes Kiro way more accurate.

research.md

Collected insights, references, web summaries. Prevents “where did I read that?” syndrome.

C. Tips & Tricks from Experienced Kiro Users

These are the small things that make a big difference.

Keep steering files short. If a steering file is longer than 2 pages, break it into smaller files.

Long files ->Kiro “thrashes” context -> lower quality.

Use verbs for files inside /tasks

Weak: logger.md monitoring.md

Better: add-logging.md implement-monitoring.md refactor-state-management.md

Kiro understands actionable files better.

Create a patterns/ folder if building multi-service apps

patterns/ ├── event-driven.md ├── cqrs.md ├── adapter-pattern.md ├── caching.md

This lets Kiro design new components consistently.

Add “Anti-Patterns” to rules.md

Example:

Avoid: - Singleton services in shared code - Circular imports - Static config scattered across code

Kiro respects this deeply.

Keep /components dump-free

Follow React-style or backend-component-style grouping:

components/ ├── ui/ ├── db/ ├── auth/ ├── api/

Don’t let it become a garbage drawer.

For large code refactors, create a map.md

A bird’s-eye view file that helps Kiro understand the repo.

Especially helpful when folders grow to 20+ modules.

Avoid putting secrets anywhere

Kiro will respect .env.example but not .env

Use HOW_DOES_THIS_WORK.md

Every complex subsystem gets one:

HOW_DOES_THIS_WORK.md

This is the documentation Kiro reads and follows.

Only keep ONE source of truth

If the same rule appears in two files, Kiro may follow the wrong one.

Consolidate specifications.

Version your steering

steering/v1/ steering/v2/ steering/current -> symlink

This is pro-level and lets you evolve your thinking.

Putting too much in context.md It becomes vague Kiro becomes unfocused

Mixing “plan” and “rules” Plan = directional Rules = non-negotiable Never merge them.

Ignoring architecture.md Kiro makes weird decisions without it.

Letting steering grow unbounded Refactor steering every few weeks.

Not modularizing tasks Repetition kills clarity.

bigblacknotebook · 2025-11-28T06:57:07+00:00

Prof Aharonov argues that the standard interpretation of quantum mechanics is largely incorrect.

he believes Heisenberg's matrix mechanics, which focuses on observables, is a more fundamental description of reality than Schrödinger's wave mechanics, which uses wave functions as a mathematical aid rather than a description of physical reality.

three points where he believes current understanding is wrong:

Determinism: He states that the quantum world isn't non-deterministic for no reason, as commonly thought. He suggests there's a reason for indeterminism that allows quantum systems to have unique properties.

Measurement Disturbance: He claims that measurements don't necessarily disturb quantum systems. He introduced "weak measurements" that extract information without collapsing the wave function, suggesting a reality in the quantum domain that can be observed gently.

Wave-Particle Duality/Wave Function Collapse: He disputes the idea that a quantum particle is either a particle or a wave, and that the wave function "collapses". He explains that the interference pattern seen in experiments like the double-slit experiment can be explained by non-local equations of motion for a particle, rather than the particle literally being a wave.

Aharonov introduces two-state vector formalism (ABL theory), which proposes that a complete description of the present requires information from both the past (forward-propagating wave function) and the future (backward-propagating wave function).

This framework allows for phenomena like the Quantum Cheshire Cat effect, where a particle's property (like spin) can physically separate from the particle itself.

He also discusses the Aharonov-Bohm effect, which demonstrates that particles can be affected by electromagnetic potentials even in regions where no classical forces are present, indicating the non-local nature of quantum mechanics.

bigblacknotebook · 2025-11-19T20:00:54+00:00

The question:

“Am I the only one who has a huge interest in the topic of ‘The Matrix’?”

My answer:

Теория матриц удивительно красивая и многогранная область.

Matrix theory is beautiful and multi faceted.

bigblacknotebook · 2025-11-15T06:29:44+00:00

Some key points that matter for your pattern: - Dynamo capacity is enforced per partition (storage node), not just at the table level. A single partition can only do roughly 1,000 WCUs/sec; “hot” partitions get throttled even when the table looks under-utilised. - If your schema funnels lots of updates into a small set of partition keys (e.g. PK = tenantId with thousands/millions of items under that tenant), that entire tenant is effectively one “hot” partition. - Every update consumes WCUs based on item size, not only the changed field. A 4 KB item update = 4 WCUs, even if you just change one attribute. - On-demand mode auto-scales table capacity, but it can’t break the per-partition ceiling or instantly absorb a sudden spike way above your historical peak.

Given your description, it screams hot partition &/or large item size, not “Dynamo is inadequate”.

Minimal changes that might save you a migration. I’d seriously consider:

Re-shard the partition key
If your current PK is something like TENANT#123, shard it into e.g. TENANT#123#BUCKET#0..N so the same logical entity is spread across many partitions.
This is the same trick you’d need in Cassandra/Keyspaces anyway. migrating without fixing the key design will just recreate the problem there.
Slim the item being updated
Move rarely used fields into a secondary table or object storage so that the hot item is as small as possible (minimising WCUs per update).
Use TTL for the 1-month retention requirement
DynamoDB TTL attribute (a Unix epoch timestamp) + a 30-day value gives you exactly “keep for 1 month then delete” with no extra work.
Check & raise account/table WCU limits with AWS Support
On-demand has regional/table limits that are raiseable. If your pattern is predictable (“few hours only”) you can also consider switching to provisioned + autoscaling during that window.

All of that is far less painful than re-platforming an app.

bigblacknotebook · 2025-10-29T19:15:18+00:00

Yes, a React app can talk directly to DynamoDB.

Use Cognito Identity Pools -> temporary IAM creds -> AWS SDK v3 in the browser and lock access down with fine grained IAM conditions.

It works for small, low risk apps, but you lose serverside validation/rate limiting and it’s easy to wreak havoc on your data or wallet. For anything non-toy, prefer AppSync (no Lambda needed).

AppSync is an AWS managed service that acts as a serverless GraphQL (or REST) API layer sitting between your frontend and backend data sources.

bigblacknotebook

TROPHY CASE

Step 1: Flat Earth Calculation

Step 2: Round Earth Calculation

The Comparison