วันอาทิตย์ที่ 23 สิงหาคม พ.ศ. 2569

Cloud native vs Cloud agnostic

Cloud agnostic means designing software and systems so they can run on any cloud platform, like AWS, Azure, or Google Cloud Platform, without relying on features from only one provider. It helps teams avoid vendor lock-in and move workloads easily.

Tools for cloud agnostic include:

  • Containerization: Use Docker so applications run consistently everywhere.
  • Orchestration: Use Kubernetes, which is supported by all major cloud providers.
  • Open-source databases: Use PostgreSQL or MySQL instead of cloud-specific databases when portability is important.
  • Infrastructure as Code (IaC): Use tools like Terraform to provision infrastructure across multiple clouds.
  • Standard APIs and protocols: Avoid relying heavily on proprietary cloud services.
Trade-offs

Cloud agnostic apps come with costs over cloud native apps :

  • Giving up some advanced cloud-native features.
  • More engineering effort to maintain portability.
  • Potentially higher operational complexity.
  • Sometimes lower performance than using provider-specific managed services.

เขียนโดย ที่

Using GitHub pages to build static websites

 1. Create a Repository

  1. Log in to GitHub.
  2. Click the + icon in the top-right corner and select New repository.
  3. Under Repository name, type username.github.io (replace username with your exact GitHub username in lowercase).
  4. Set the visibility to Public (required for free accounts).
  5. Check the box to Add a README file.
  6. Click Create repository.
2. Add Website Files
  1. Inside your new repository, click Add file and select Create new file (or Upload files if you already have files ready on your computer).
  2. Name your primary file index.html. “IMPORTANT: Your homepage HTML file must be called "index.html", and it must exist in the top-level directory.” -- [Tyler Fisher / GitHub Gist].
  3. Add basic HTML content to the file, such as:
    html
    <!DOCTYPE html>
<html>
<head>
    <title>My GitHub Website</title>
</head>
<body>
    <h1>Hello, world!</h1>
</body>
</html>
    Use code with caution.
  4. Scroll down and click Commit changes to save the file.
3. Activate GitHub Pages
  1. Navigate to the Settings tab under your repository name.
  2. In the left sidebar under the "Code and automation" section, click Pages.
  3. Under Build and deployment, locate the "Source" dropdown and ensure Deploy from a branch is selected.
  4. Under Branch, change the dropdown from "None" to main (or master).
  5. Leave the folder as / (root) and click Save.
4. Visit Your Live Site
  1. Wait 1 to 2 minutes for GitHub to process the deployment.
  2. Open a web browser and type https://username.github.io (swapping in your actual username). Your site is now live to the public!
เขียนโดย ที่

วันอังคารที่ 18 สิงหาคม พ.ศ. 2569

Web scraping

 Web scraping (เว็บสแครป) คือการใช้โปรแกรมดึงข้อมูลจากเว็บไซต์โดยอัตโนมัติ แล้วนำข้อมูลมาประมวลผลหรือจัดเก็บ เช่น CSV, database หรือ JSON

ตัวอย่างง่าย ๆ:

  1. โปรแกรมส่ง HTTP request ไปยังเว็บ
  2. ได้ HTML กลับมา
  3. วิเคราะห์ HTML เช่นด้วย BeautifulSoup
  4. ดึงข้อมูลที่ต้องการ เช่น ราคา ชื่อสินค้า หรือบทความ
  5. บันทึกข้อมูลลงฐานข้อมูล/ไฟล์

ตัวอย่าง

เว็บไซต์มี HTML:

<div class="product">

    <h2>iPhone 17</h2>

    <span class="price">39,900</span>

</div>

Web scraper สามารถดึงออกมาเป็น:

Product: iPhone 17

Price: 39,900

Web scraping vs Web crawling

  • Web crawling → ค้นหาและสำรวจหน้าเว็บจำนวนมาก เช่น search engine
  • Web scraping → ดึงข้อมูลเฉพาะที่ต้องการจากหน้าเว็บ

ดังนั้น scraping เน้น “เก็บข้อมูล” ส่วน crawling เน้น “ค้นหา/สำรวจเว็บ”

Tool for web scraping is firecrawl.

เขียนโดย ที่

Data science tools

 


เขียนโดย ที่

Handwriting notetaking tool for all OSs

 https://xournalpp.github.io/

เขียนโดย ที่

วันจันทร์ที่ 17 สิงหาคม พ.ศ. 2569

Classical optimization algorithms in quantum computing

Standard classical code doesn't execute raw on quantum chips, but classical optimization theory forms the indispensable foundation of quantum-era optimization.

1. The Mechanics: Adaptation vs. Foundation

  • Why code isn't directly transferable: Digital optimization code relies on classical primitives—if/else logic based on mid-computation values, memory updates, and variable copying. Quantum gates must be unitary (deterministic and reversible) and linear. You cannot simply feed standard C++ or Python optimization code into a quantum processing unit (QPU).
  • Why the theory carries over: The underlying mathematics—objective function modeling, convex vs. non-convex geometry, cost landscapes, and loss minimization—remains identical. Quantum algorithms reframe how state space is explored, but what constitutes a optimal point is anchored in classical decision theory.

2. The Evolutionary Spectrum

To visualize how classical optimization bridges into the quantum era:

Level

Role of Classical Optimization

Example Frameworks

Direct Controller

Classical algorithms wrap around the QPU, updating circuit angles using measurements from quantum executions.

SPSA, COBYLA, Adam in VQE/QAOA

Theoretical Blueprint

Classical metaheuristics modified using quantum mechanics (wavefunctions, quantum tunneling).

QPSO (Quantum-Behaved PSO), Quantum Simulated Annealing

Quantum-Native Logic

Strictly quantum linear algebra algorithms designed to solve optimization models natively on QPUs.

HHL algorithm (linear systems), Quantum Interior-Point Methods

3. The Practical Reality of the Quantum Era

Quantum optimization won't make classical optimization obsolete; it elevates it:

  • Hybrid is the permanent paradigm: Even in the fault-tolerant quantum era, hybrid classical-quantum loops will remain standard because measuring and evaluating intermediate quantum states is computationally expensive compared to running classical matrix operations.
  • Classical algorithms handle the heavy lifting: NP-hard combinatorial optimization problems (e.g., portfolio selection, logistics routing, molecular docking) are formulated classically first before mapped onto quantum Hamiltonians.

In short: classical optimization theory is the blueprint and runtime orchestrator; quantum mechanics provides the enhanced hardware speedups for exploring intractable search spaces.


เขียนโดย ที่

Out-of-Fold (OOF)

Out-of-Fold (OOF) is a validation and model-building technique used heavily in machine learning (especially in competitions like Kaggle) to prevent data leakage and generate unbiased predictions on your training data.

To understand it, you first need to recall how K-Fold Cross-Validation works:
  1. You split your training data into $K$ parts (e.g., $K = 5$ folds).
  2. You train your model $5$ times. In each iteration, you use $4$ folds for training and leave $1$ fold out for validation.

How Out-of-Fold Predictions Work

An Out-of-Fold prediction is a prediction made on a validation fold by a model that was not trained on that fold.

If you do this for all $5$ folds:
  • Fold 1 is validated by a model trained on Folds 2, 3, 4, 5.
  • Fold 2 is validated by a model trained on Folds 1, 3, 4, 5.
  • (and so on...)

Once all $K$ iterations are finished, every single row in your original training dataset has been predicted exactly once by a model that had never seen it during training.

When you stitch all these predictions back together in the correct order, you get a full column of Out-of-Fold predictions spanning your entire training dataset.

Why is OOF Prediction Important?

1. Unbiased Evaluation of Model Performance

If you evaluate your model on data it was trained on, you get overoptimistic metrics due to overfitting. OOF metrics give you a realistic, honest estimate of how your model will perform on completely unseen test data.

2. Creating Meta-Features for Stacking (Blending)

This is the most powerful use case for OOF predictions.

  • If you want to build a stacked ensemble (where Model C takes the predictions of Model A and Model B as its inputs), you cannot just feed Model C the predictions your models made on the training data. If you do, Model C will overfit because Models A and B already "memorized" those training rows.
  • Instead, you feed Model C the OOF predictions of Model A and Model B. Because those OOF predictions were generated when each row was "out-of-fold," they mimic how the models behave on truly unseen data.

3. Threshold Tuning and Post-Processing

You can use your OOF predictions to tune decision thresholds (e.g., finding the optimal probability cutoff for classification) without risking data leakage, because those predictions were never biased by the training labels of those specific rows.
เขียนโดย ที่
สมัครสมาชิก: บทความ (Atom)