Tech on Pavan Yarahttps://pavanyara.com/tags/tech/Recent content in Tech on Pavan YaraHugo -- gohugo.ioen-USpavan.yara@gmail.com (Pavan Yara)pavan.yara@gmail.com (Pavan Yara)Pavan YaraWed, 21 Sep 2022 14:11:24 +0530Rules of Debugginghttps://pavanyara.com/blog/rules-of-debugging/Wed, 21 Sep 2022 14:11:24 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/rules-of-debugging/<p>Here is a list of David J.Agan&rsquo;s timeless and universal rules of debugging. As the author notes in the book - <strong>Memorize them. Tape them to your wall. Tape them to all of your walls.</strong></p> <ol> <li><strong>Understand the System</strong>: Read the manual. Read everything in Depth. Know the Fundamentals. Know the road map. Understand your tools. Look up the details</li> <li><strong>Make it Fail</strong>: Do it Again. Start at the Beginning. Stimulate the Failure. Don&rsquo;t Simulate the Failure. Find the uncontrolled condition that makes it intermittent. Record everything and find the signature of intermittent bugs. Don&rsquo;t trust Statistics too much. Know that &ldquo;that&rdquo; can happen. Never throw away a Debugging tool.</li> <li><strong>Quit Thinking and Look</strong>: Get Data First. Don&rsquo;t just do Complicated repairs based on guess game. See the Failure. See the Details. Build Instrumentation in. Add Instrumentation on. Don&rsquo;t be afraid to Dive-in. Watch out for Heisenberg. Guess only to focus the Search.</li> <li><strong>Divide and Conquer</strong>: Narrow the Search with successive Approximation. Get the Range. Determine which side of the Bug you are on. Use Easy-to-use test patterns. Start with the Bad. Fix the bugs you know about. Fix the noise first.</li> <li><strong>Change One Thing at a Time</strong>: Isolate the key factor. Grab the brass bar with both hands (i.e., understand what&rsquo;s wrong before fixing). Change one test at a time. Compare it with a good one. Determine what you changed since the last time it worked.</li> <li><strong>Keep an Audit Trail</strong>: Write down what you did in what order and what happened as a result. Understand that any detail could be the important one. Correlate Events. Understand that audit trails for design are also good for testing. Write it Down!</li> <li><strong>Check the Plug</strong>: Question your assumptions. Start at the Beginning. Test the Tool.</li> <li><strong>Get a Fresh View</strong>: Ask for Fresh Insights (aka explaining the problem to a mannequin/dummy). Tap expertise. Listen to the voice of Experience. Know that help is all around you. Don&rsquo;t be Proud. Report symptoms (not theories). Realize that you don&rsquo;t have to be Sure.</li> <li><strong>If you don&rsquo;t Fix it, it Ain&rsquo;t Fixed</strong>: Check that it&rsquo;s actually/really fixed. Check that it&rsquo;s really your fix that fixed it. Know that it never just goes away by itself. Fix the Cause. And, fix the Process.</li> </ol>Here is a list of David J.Agan’s timeless and universal rules of debugging. As the author notes in the book - Memorize them. Tape them to your wall. Tape them to all of your walls.

  1. Understand the System: Read the manual. Read everything in Depth. Know the Fundamentals. Know the road map. Understand your tools. Look up the details
  2. Make it Fail: Do it Again. Start at the Beginning. Stimulate the Failure. Don’t Simulate the Failure. Find the uncontrolled condition that makes it intermittent. Record everything and find the signature of intermittent bugs. Don’t trust Statistics too much. Know that “that” can happen. Never throw away a Debugging tool.
  3. Quit Thinking and Look: Get Data First. Don’t just do Complicated repairs based on guess game. See the Failure. See the Details. Build Instrumentation in. Add Instrumentation on. Don’t be afraid to Dive-in. Watch out for Heisenberg. Guess only to focus the Search.
  4. Divide and Conquer: Narrow the Search with successive Approximation. Get the Range. Determine which side of the Bug you are on. Use Easy-to-use test patterns. Start with the Bad. Fix the bugs you know about. Fix the noise first.
  5. Change One Thing at a Time: Isolate the key factor. Grab the brass bar with both hands (i.e., understand what’s wrong before fixing). Change one test at a time. Compare it with a good one. Determine what you changed since the last time it worked.
  6. Keep an Audit Trail: Write down what you did in what order and what happened as a result. Understand that any detail could be the important one. Correlate Events. Understand that audit trails for design are also good for testing. Write it Down!
  7. Check the Plug: Question your assumptions. Start at the Beginning. Test the Tool.
  8. Get a Fresh View: Ask for Fresh Insights (aka explaining the problem to a mannequin/dummy). Tap expertise. Listen to the voice of Experience. Know that help is all around you. Don’t be Proud. Report symptoms (not theories). Realize that you don’t have to be Sure.
  9. If you don’t Fix it, it Ain’t Fixed: Check that it’s actually/really fixed. Check that it’s really your fix that fixed it. Know that it never just goes away by itself. Fix the Cause. And, fix the Process.
]]>The Tech Stack of a One-Man SaaShttps://pavanyara.com/blog/tech-stack-one-man-saas/Mon, 21 Dec 2020 23:21:39 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/tech-stack-one-man-saas/<p>It&rsquo;s amazing how much complexity one person can wrangle.</p> <p>In a post - <a href="https://panelbear.com/blog/tech-stack/">The Tech Stack of a One-Man SaaS</a>:</p> <ul> <li> <p>treat infrastructure as cattle instead of pets</p> </li> <li> <p>choose boring technology</p> </li> <li> <p>Moved DigitalOcean to Linode because of stability issues. Then moved to AWS due to a good deal.</p> </li> <li> <p>Migrations were relatively easy because the infrastructure was described via Terraform and Kubernetes manifests.</p> </li> <li> <p>Stack</p> </li> </ul> <ul> <li> <p>Python/Typescript</p> </li> <li> <p>Django/React/NextJS/Celery/Bootstrap 4</p> </li> <li> <p>Clickhouse/PostgreSQL/Redis/RDS</p> </li> <li> <p>Terraform/Docker/K8s/GitHub Actions</p> </li> <li> <p>AWS/Cloudflare/Let&rsquo;s Encrypt/Namecheap</p> </li> <li> <p>Prometheus/Grafana/Sentry/Loki</p> </li> <li> <p>Fastmail/Sendgrid</p>It’s amazing how much complexity one person can wrangle.

In a post - The Tech Stack of a One-Man SaaS:

  • treat infrastructure as cattle instead of pets

  • choose boring technology

  • Moved DigitalOcean to Linode because of stability issues. Then moved to AWS due to a good deal.

  • Migrations were relatively easy because the infrastructure was described via Terraform and Kubernetes manifests.

  • Stack

  • Python/Typescript

  • Django/React/NextJS/Celery/Bootstrap 4

  • Clickhouse/PostgreSQL/Redis/RDS

  • Terraform/Docker/K8s/GitHub Actions

  • AWS/Cloudflare/Let’s Encrypt/Namecheap

  • Prometheus/Grafana/Sentry/Loki

  • Fastmail/Sendgrid

  • GitHub/PyCharm/VS Code/Poetry/Yarn/Invoked

A Hackernews discussion shares similar experiences by other successful one-person SaaS founders.

]]>Notes on API Practiceshttps://pavanyara.com/blog/api-practices-1/Wed, 18 Dec 2019 22:21:54 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/api-practices-1/<table> <thead> <tr> <th>Technique</th> <th>Treat customers with disdain</th> <th>Show customers love</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>Don&rsquo;t have an API</td> <td>Have an API</td> </tr> <tr> <td>2</td> <td>Make signups difficult, users must justify their request</td> <td>Self-service onboarding</td> </tr> <tr> <td>3</td> <td>Exorbitant fees for the privilege of API access</td> <td>Enable API access for free or as part of an &ldquo;enterprise-level&rdquo; package</td> </tr> <tr> <td>4</td> <td>API documentation behind login page or otherwise hidden from search engines</td> <td>API documentation freely accessible and referenced by public search engines</td> </tr> <tr> <td>5</td> <td>Use a proprietary or terrible protocol</td> <td>Use an industry-standard protocol such as JSON:API or gRPC (<a href="https://grpc.io">https://grpc.io</a>)</td> </tr> <tr> <td>6</td> <td>Permit only one API key</td> <td>Permit multiple API keys for each rotation</td> </tr> <tr> <td>7</td> <td>Tempt fate by maintaining documentation manually</td> <td>Keep documentation in sync with code using automated systems such as Swagger or gRPC</td> </tr> <tr> <td>8</td> <td>Ignore the infrastructure as code (IaC) revolution</td> <td>Make IaC a top priority: Provide officially supported modules for Terraform, Chef, Puppet, Chocolatey, and similar systems</td> </tr> <tr> <td>9</td> <td>Design APIs to be non-idempotent whenever possible</td> <td>Design APIs to be idempotent whenever possible</td> </tr> </tbody> </table> <ul> <li>via Thomas A. Limoncelli&rsquo;s excellent <a href="https://queue.acm.org/detail.cfm?id=3375635">ACM queue column on APIs</a></li> </ul> Technique Treat customers with disdain Show customers love 1 Don’t have an API Have an API 2 Make signups difficult, users must justify their request Self-service onboarding 3 Exorbitant fees for the privilege of API access Enable API access for free or as part of an “enterprise-level” package 4 API documentation behind login page or otherwise hidden from search engines API documentation freely accessible and referenced by public search engines 5 Use a proprietary or terrible protocol Use an industry-standard protocol such as JSON:API or gRPC (https://grpc.io) 6 Permit only one API key Permit multiple API keys for each rotation 7 Tempt fate by maintaining documentation manually Keep documentation in sync with code using automated systems such as Swagger or gRPC 8 Ignore the infrastructure as code (IaC) revolution Make IaC a top priority: Provide officially supported modules for Terraform, Chef, Puppet, Chocolatey, and similar systems 9 Design APIs to be non-idempotent whenever possible Design APIs to be idempotent whenever possible ]]>Some AWS EC2 Tipshttps://pavanyara.com/blog/ec2-tips-1/Wed, 18 Dec 2019 10:37:41 +0530pavan.yara@gmail.com (Pavan Yara)https://pavanyara.com/blog/ec2-tips-1/<ul> <li><strong>Choosing right instance size</strong></li> </ul> <p><img src="https://pavanyara.com/img/ec2.png" alt="Choosing Right Ec2 instance size"></p> <ul> <li><strong>Why is my Linux instance not booting after I changed its type to C5 or M5?</strong></li> </ul> <p>See <a href="https://aws.amazon.com/premiumsupport/knowledge-center/boot-error-linux-m5-c5/">https://aws.amazon.com/premiumsupport/knowledge-center/boot-error-linux-m5-c5/</a></p> <ul> <li><strong>Make sure enaSupport instance attribute is enabled</strong></li> </ul> <blockquote> <p>aws ec2 describe-instances &ndash;instance-ids instance_id &ndash;query &ldquo;Reservations[].Instances[].EnaSupport“</p> </blockquote> <ul> <li><strong>Make sure both ENA and NVMe modules are installed</strong></li> </ul> <blockquote> <p>modinfo ena</p> </blockquote> <blockquote> <p>lsinitrd /boot/initramfs-$(uname -r).img|grep nvme</p> </blockquote> <ul> <li><strong>Mount EBS volumes using UUID/Label instead of device name</strong></li> </ul> <blockquote> <p>/dev/sda1 -&gt; UUID=&ldquo;ca774df7-756d-4261-a3f1-76038323e572&rdquo;</p> </blockquote>
  • Choosing right instance size

    • Choosing Right Ec2 instance size

    • Why is my Linux instance not booting after I changed its type to C5 or M5?

    See https://aws.amazon.com/premiumsupport/knowledge-center/boot-error-linux-m5-c5/

    • Make sure enaSupport instance attribute is enabled

    aws ec2 describe-instances –instance-ids instance_id –query “Reservations[].Instances[].EnaSupport“

    • Make sure both ENA and NVMe modules are installed

    modinfo ena

    lsinitrd /boot/initramfs-$(uname -r).img|grep nvme

    • Mount EBS volumes using UUID/Label instead of device name

    /dev/sda1 -> UUID=“ca774df7-756d-4261-a3f1-76038323e572”

    ]]>