Forem: Cherrypick14

Understanding secp256k1 & Multisig Wallets

Cherrypick14 — Thu, 12 Feb 2026 17:11:57 +0000

A Deep Dive into Elliptic Curve Cryptography with Rust

"What is needed is an electronic payment system based on cryptographic proof instead of trust." — Satoshi Nakamoto

Every day, millions of transactions flow through Bitcoin and Ethereum networks. Yet, surprisingly few developers truly understand the cryptographic foundation that makes it all possible: secp256k1, the elliptic curve that powers both blockchains.

While building my multisig wallet in Rust, I realized that most developers (including myself initially) treat elliptic curve cryptography as a black box. We import libraries, call functions, and trust that magic happens.

This article changes that. We're going to demystify secp256k1, understand how multisig wallets work, and see why Rust is the perfect language for building cryptographic systems.

What is secp256k1

secp256k1 is an elliptic curve defined by the equation:

The secp256k1 Equation:

y² = x³ + 7 (over a finite field)

This deceptively simple equation creates a curve with remarkable properties:

Point Addition: You can "add" points on the curve to get another point.
Scalar Multiplication: Multiplying a point by a number gives you a new point.
One-way Function: Easy to go from private key → public key, impossible to reverse.

Why this Curve?

Bitcoin's creator chose secp256k1 for several reasons:

Efficiency: The equation y² = x³ + 7 has no 'x²' or 'x' terms, making computations faster.
Security: 256-bit key space = 2²⁵⁶ possible keys (more atoms than in the observable universe).
Non-NSA: Unlike some curves (like NIST P-256), secp256k1's constants weren't chosen by government agencies.

How Cryptographic Keys Work

Here's what happens under the hood:

Private Key (256-bit random number):

0x1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b1c2d3e4f5a6b7c8d9e0f1a2b

Public Key (Point on the curve) :

Apply point multiplication: PublicKey = PrivateKey × G
Where G is the generator point (a fixed point on secp256k1)

Address :

Hash the public key with SHA256 + RIPEMD160, add checksums → Your wallet address

Multisig Wallets: Shared Ownership

Now that we understand single-key cryptography, let's level up to multisignature (multisig) wallets.

What is a Multisig Wallet?

A wallet that requires M out of N signatures to authorize a transaction.

Examples:

1. 2-of-3: Company wallet (CEO, CFO, CTO — any 2 can approve).
2. 3-of-5: DAO treasury (requires majority approval).
3. 1-of-2: Personal backup (main key + recovery key).

Why Multisig Matters

Security: No single point of failure. Lose one key? Still safe.
Governance: Requires consensus for major decisions.
Trust Minimization: No need to trust a single party.
Recovery: Built-in key recovery mechanisms.

Building It in Rust: Why?

Rust isn't just a trendy language — it's perfect for cryptography:

// Rust's type system prevents common crypto bugs
pub struct PrivateKey([u8; 32]);  // Exactly 32 bytes, no more, no less

impl PrivateKey {
    // Ownership system ensures keys aren't accidentally copied
    pub fn sign(&self, message: &[u8]) -> Signature {
        // Compile-time guarantee of memory safety
        // No buffer overflows, no use-after-free
    }
}

// Error handling forces you to handle failures
match wallet.verify_signature(&tx, &sig) {
    Ok(valid) => { /* proceed */ },
    Err(e) => { /* must handle error */ },
}

Key Rust advantages for cryptography:

Memory Safety: No buffer overflows that could leak keys.
Zero-cost Abstractions: High-level code compiles to fast assembly.
Explicit Error Handling: Cryptographic failures can't be ignored.
No Garbage Collection: Predictable performance, no unexpected pauses.

Building in Rust: Core Architecture

Here's a typical structure for a multisig wallet in Rust. This demonstrates the key concepts — the actual implementation in my GitHub repository includes additional features like transaction queuing, enhanced serialization, and more robust error handling:

// Core data structures
pub struct MultisigWallet {
    pub threshold: usize,           // M in M-of-N
    pub signers: Vec<PublicKey>,    // N public keys
    pub nonce: u64,                 // Prevent replay attacks
}

pub struct Transaction {
    pub to: Address,
    pub amount: u64,
    pub nonce: u64,
}

// The critical signing and verification functions
impl MultisigWallet {
    pub fn create_signature(
        &self,
        tx: &Transaction,
        private_key: &PrivateKey,
    ) -> Result<Signature, Error> {
        // Hash the transaction
        let msg_hash = hash_transaction(tx);

        // Sign with secp256k1
        sign_ecdsa(&msg_hash, private_key)
    }

    pub fn verify_and_execute(
        &mut self,
        tx: &Transaction,
        signatures: Vec<Signature>,
    ) -> Result<(), Error> {
        // Verify we have enough signatures
        if signatures.len() < self.threshold {
            return Err(Error::InsufficientSignatures);
        }

        // Verify each signature is from a valid signer
        let msg_hash = hash_transaction(tx);

        for sig in signatures.iter().take(self.threshold) {
            let pub_key = recover_public_key(&msg_hash, sig)?;

            if !self.signers.contains(&pub_key) {
                return Err(Error::UnauthorizedSigner);
            }
        }

        // Execute transaction
        self.execute_transaction(tx)
    }
}

The Challenges I Faced

1. Signature Verification Edge Cases

Challenge: What if the same key signs twice? What if signatures are in wrong order?
Solution: Recover the public key from each signature and check against the signer list. Use HashSets to prevent duplicate signatures.

2. Transaction Replay Attacks

Challenge: Without nonces, an attacker could replay old valid transactions.
Solution: Include a nonce that increments with each transaction. Old transactions become invalid.

3. Key Serialization

Challenge: Public keys can be compressed (33 bytes) or uncompressed (65 bytes).
Solution: Always use compressed format for consistency. Rust's type system helps enforce this.

What I Learned

Cryptography is unforgiving: One byte wrong = complete failure. Rust's strictness is a feature, not a bug.
Testing is critical: Test with known test vectors, fuzz testing, property-based testing.
Understanding beats memorization: Knowing why secp256k1 works makes debugging infinitely easier.
Error handling is security: Every Result is a potential vulnerability if mishandled.

Key Takeaways

Try It Yourself

The complete implementation is open source and documented. Here's what you'll find:

Full secp256k1 signature creation and verification.
M-of-N multisig wallet implementation.
Transaction serialization and hashing.
Comprehensive error handling.
Test suite with known test vectors.

If you found this helpful , leave a comment or feedback. Any Questions? Found a bug? Want to contribute?

Open an issue or PR - let's build secure crypto systems together! 🦀

How to Build a Real-Time Blockchain Dashboard with PAPI

Cherrypick14 — Mon, 13 Oct 2025 15:18:09 +0000

Blockchain developers have long struggled with the complexity of connecting to and querying blockchain networks. Traditional APIs often require extensive boilerplate code, lack type safety, and make real-time data subscriptions cumbersome. Enter Polkadot API (PAPI) - a modern, TypeScript-first API that revolutionizes how we interact with Polkadot and its parachains.

In this article, I'll walk you through building Polkadot Network Pulse, a real-time blockchain monitoring dashboard that showcases PAPI's powerful features. By the end, you'll understand how to leverage PAPI's reactive subscriptions, WebSocket connections, and type-safe queries to build production-ready blockchain applications.

🔗 Live Demo: https://polkadot-network-pulse.vercel.app/

📦 Source Code: https://github.com/Cherrypick14/polkadot-network-pulse

What is PAPI?

Polkadot API (PAPI) is the next-generation JavaScript/TypeScript library for interacting with Polkadot and Substrate-based chains. It's a complete rewrite of the legacy @polkadot/api with several key improvements:

Why PAPI Over Legacy @polkadot/api?

Project Overview: Polkadot Network Pulse

Polkadot Network Pulse is a real-time dashboard that monitors the Polkadot blockchain, displaying:

Latest block updates (streaming in real-time)
Finalized block numbers
Average block time calculations
Live block feed with animations
Connection status monitoring

The goal is to demonstrate PAPI's core strengths: reactive subscriptions and WebSocket-based real-time data streaming.

Technical Architecture
Tech Stack

Frontend: React 19 with TypeScript
Blockchain API: Polkadot API (PAPI) v1.20+
Styling: Tailwind CSS v4
Build Tool: Vite
Icons: Lucide React

Architecture Diagram

Implementation Deep Dive

1. Setting Up PAPI
First, install the required dependencies:

npm install polkadot-api
npm install @polkadot-api/descriptors

2. Creating the PAPI Client
The foundation of any PAPI application is the client creation:

import { createClient } from "polkadot-api";
import { getWsProvider } from "polkadot-api/ws-provider/web";

// Create WebSocket provider
const provider = getWsProvider("wss://rpc.polkadot.io");

// Initialize PAPI client
const client = createClient(provider);

Key Insight: Unlike the legacy API, PAPI uses a provider pattern that separates connection management from client logic. This makes testing and switching between networks trivial.

3. Real-Time Block Subscriptions
This is where PAPI truly shines. Instead of polling for new blocks, we subscribe to observables:

// Subscribe to best (latest) blocks
client.bestBlocks$.subscribe((blocks) => {
  for (const block of blocks) {
    const blockInfo = {
      number: block.number,
      hash: block.hash,
      timestamp: Date.now(),
    };

    setLatestBlock(blockInfo);

    // Update block feed
    setRecentBlocks((prev) => [blockInfo, ...prev].slice(0, 15));
  }
});

// Subscribe to finalized blocks
client.finalizedBlock$.subscribe((block) => {
  setFinalizedBlock(block.number);
});

Why Observables?

Reactive: Automatically updates when new data arrives.
Memory Efficient: Unsubscribe when component unmounts.
Composable: Easy to combine multiple data streams.
Error Handling: Built-in error propagation.

4. Calculating Block Time
One interesting metric is the average block time. We calculate this by comparing timestamps of recent blocks:

const calculateBlockTime = () => {
  if (recentBlocks.length < 2) return null;

  const timeDiff = recentBlocks[0].timestamp - 
                   recentBlocks[recentBlocks.length - 1].timestamp;
  const blockDiff = recentBlocks[0].number - 
                    recentBlocks[recentBlocks.length - 1].number;

  return (timeDiff / blockDiff / 1000).toFixed(2); // in seconds
};

This gives us a live, measured block time rather than relying on hardcoded values.

5. Managing Connection State
Proper connection management is crucial for production apps:

const [isConnected, setIsConnected] = useState(false);
const [error, setError] = useState<string | null>(null);
const [loading, setLoading] = useState(false);

const connectToPolkadot = async () => {
  try {
    setLoading(true);
    setError(null);

    const provider = getWsProvider("wss://rpc.polkadot.io");
    const client = createClient(provider);

    setIsConnected(true);
    // ... set up subscriptions
  } catch (err) {
    setError(err instanceof Error ? err.message : "Connection failed");
    setIsConnected(false);
  } finally {
    setLoading(false);
  }
};

Key PAPI Concepts Explained

1. Observables vs. Promises
Traditional APIs use promises for async operations:

// Legacy approach (promise)
const block = await api.rpc.chain.getBlock();

PAPI uses observables for continuous data:

// PAPI approach (observable)
client.bestBlocks$.subscribe(blocks => {
  // Automatically receives updates
});

Benefits:

No need to repeatedly poll
Lower network overhead
Real-time updates
Automatic cleanup

2. WebSocket Provider
PAPI's WebSocket provider maintains a persistent connection:

const provider = getWsProvider("wss://rpc.polkadot.io");

Features:

Automatic reconnection on disconnect
Connection pooling
Request queuing
Error recovery

3. Type Safety
One of PAPI's biggest advantages is full TypeScript support. While we didn't use typed APIs extensively in this project (focusing on subscriptions), here's how they work:

// Get typed API with chain-specific types
const typedApi = client.getTypedApi(chainSpec);

// TypeScript knows all available queries
const validators = await typedApi.query.Session.Validators.getValue();
// validators is properly typed!

Challenges & Solutions

Challenge 1: PAPI API Changes

Problem: PAPI is actively developed, and APIs change between versions.

Solution: Focused on stable core features (subscriptions) rather than experimental typed queries. Always check the official docs - https://papi.how

Challenge 2: Handling Reconnections

Problem: WebSocket connections can drop unexpectedly.

Solution: PAPI's provider handles this automatically. We just need to show connection state to users:

{isConnected && (
  <div className="flex items-center gap-2">
    <div className="w-3 h-3 bg-green-500 rounded-full animate-pulse" />
    <span>Live Connected</span>
  </div>
)}

Challenge 3: Performance with Rapid Updates

Problem: New blocks every ~6 seconds can cause performance issues.

Solution: Limit the block feed to 15 most recent blocks:

setRecentBlocks((prev) => [blockInfo, ...prev].slice(0, 15));

Performance Considerations

1. Bundle Size
PAPI significantly reduces bundle size compared to legacy API:

Legacy @polkadot/api: ~500KB+ .
PAPI: ~100KB base + only what you use.

2. Memory Management
Always unsubscribe from observables when components unmount:

useEffect(() => {
  const subscription = client.bestBlocks$.subscribe(/* ... */);

  return () => {
    subscription.unsubscribe(); // Cleanup
  };
}, []);

3. Connection Pooling

PAPI automatically manages connection pooling, so multiple subscriptions share the same WebSocket connection.

Deployment

Build for Production

npm run build

Vercel (Preference):

Push code to GitHub
Import project in Vercel
Deploy automatically

Note: Alternative Deployment When Vercel UI Fails

When I first tried deploying through the Vercel dashboard, I ran into this error:

sh: line 1: vite: command not found
Error: Command "vite build" exited with 127

This happens sometimes when the build environment can’t find your local dev dependencies (like Vite).

Instead of getting stuck, I used a different approach that worked perfectly — deploying through Vercel CLI.

Here’s what I did:

Just for more flexibility and if you want more control, the CLI route is smooth:

npm install -g vercel
vercel login
vercel

During the setup:

Set the build command to npm run build
Output directory: dist
Confirm project name or leave defaults

Within seconds, your PAPI app will be live with a URL like:

https://your-app-name.vercel.app

💡 Pro tip: The CLI often works better than the UI if you’re using a custom front-end tool-chain or need to debug build errors locally before deployment.

Netlify:

Run npm run build
Drag dist/ folder to Netlify Drop
Done!

Environment Variables:

If using different RPC endpoints, add .env:

VITE_RPC_ENDPOINT=wss://rpc.polkadot.io

Lessons Learned

1. PAPI is Production-Ready

Despite being newer than the legacy API, PAPI is stable and performant. The developer experience is significantly better.

2. Observables Are Powerful

RxJS observables might seem complex at first, but they're perfect for blockchain data that updates continuously.

3. Type Safety Catches Bugs Early

TypeScript integration means fewer runtime errors and better IDE autocomplete.

4. Start Simple

Focus on core features (subscriptions) before diving into complex queries. PAPI's strength is real-time data.

What's Next?

Potential enhancements for this project:

Historical Data: Query past blocks and create charts.
Transaction Monitoring: Subscribe to extrinsics in real-time
Multi-Chain Support: Connect to parachains (Kusama, Acala, etc.)
Account Tracking: Monitor specific account balances.
Governance Dashboard: Track referendums and votes.
Performance Metrics: Add more network statistics.

Useful Resources

📚 - PAPI Official Documentation - https://papi.how
🔧 - PAPI Github - https://github.com/polkadot-api/polkadot-api
🌐 - Polkadot Network - https://polkadot.network
💬 - Polkadot Discord - https://discord.gg/polkadot

Conclusion

Building Polkadot Network Pulse demonstrated that PAPI is a significant leap forward for Polkadot development. The combination of TypeScript support, reactive subscriptions, and a clean API makes it the ideal choice for modern blockchain applications.

Whether you're building a block explorer, DeFi dashboard, or governance tool, PAPI provides the tools you need to create responsive, type-safe applications with minimal boilerplate.

Key Takeaways:

PAPI simplifies real-time blockchain data subscriptions
Observables provide elegant solutions for continuous data streams
TypeScript integration catches errors at compile-time
WebSocket providers handle connection management automatically
Smaller bundle sizes improve application performance

Ready to build with PAPI? Start with the official documentation -https://papi.how and experiment with subscriptions. The future of Polkadot development is here!

About Me:

Hey folks 👋 I’m Cheryl, a Full-Stack and Blockchain Developer. I enjoy turning complex technical concepts into clear, easy-to-grasp content through technical writing.

Let's connect here:
My github: https://github.com/Cherrypick14
X(Twitter) : https://x.com/OwalaCheryl

Found this helpful? Drop a ❤️ and follow for more blockchain development content!

🦀 5 Rust Concepts You Must Understand When Building on Polkadot

Cherrypick14 — Fri, 04 Jul 2025 20:30:06 +0000

No Jargon. No Headaches. Just the Good Stuff.

So, you want to build on Polkadot? Nice. But let’s be honest, jumping into smart contract development without understanding Rust is like showing up to a Formula 1 race on a bicycle.
You need the right engine.

But don’t worry, I’m not here to drown you in complex theory. I’m here to break down the five Rust concepts you really need to survive and thrive when building ink! smart contracts on Polkadot.

Let’s ride 🚴‍♂️💨.

1. Ownership and Borrowing – The VIP Pass to Rustland

Rust is picky about who owns what and honestly, it’s for your own safety.
Ownership in Rust is like having a house key. If you give it away, you can’t get back in unless you borrow it politely.

In smart contracts, this isn’t just theory ~ if you mess this up, you can cause storage errors, panics, or inefficient memory usage that cost you gas (the blockchain’s version of real money).

And trust me, Polkadot’s runtime isn’t going to hold your hand.
👉 You’ll need to carefully decide:

Should I move this data?
Should I just borrow it?
Should I clone it? (But wait ~ cloning is like copying an entire building instead of sharing the keys. Choose wisely.)

Bottom line:
Understanding ownership and borrowing isn’t optional ~ it’s literally how you keep your contract from falling apart.

2. no_std – The Stripped-Down, No-Nonsense Rust

When you write regular Rust, you have access to the full toolbox: file systems, threads, fancy libraries ~ you name it.

But when you build smart contracts on Polkadot, you get the ‘camping edition’ of Rust.
No kitchen, no electricity. You’re out here with a tent and a flashlight. Welcome tono_std.

In simple terms:

The standard library (std) is gone.
No file storage.
No threading.
No OS support.

👉 You’ll only work with what fits in the lightweight, super-restricted WebAssembly (Wasm) world.

It’s kind of like trying to cook a five-star meal with a camping stove.
Possible? Yes.
But you better know what you’re doing.

3. Traits – The Smart Contract’s Secret Handshake

In Rust, traits are like contracts for your contracts.
They say, “Hey, if you implement this trait, you promise to provide these methods.”

In Polkadot smart contracts, traits help you define what your contract can do and how other contracts can talk to you.

Think of traits like this:
👉 If your smart contract was a restaurant, the trait is your menu. It tells everyone exactly what they can order.
👉 No trait? No service.

If you plan to do cross-contract communication (basically, smart contracts calling each other like besties), traits will keep your project from turning into a spaghetti mess.

Learn how to cook with traits early. Your future self will thank you.

4. Error Handling – Unwrap Carefully, It’s Hot!

Look, in Rust, we all get tempted to use unwrap or expect to quickly get results out ofOption or Result.
But in smart contracts?
That’s like defusing a bomb with your eyes closed. One wrong unwrap, and boom ~ your transaction is gone, and you’ve wasted gas.

In Polkadot smart contracts, panicking can:

💸 Waste the caller’s gas.
🚫 Revert the entire transaction.
😬 Break user trust.

So instead of forcing results, handle errors gracefully.
👉 Always use Result or Option properly.
👉 Return helpful errors instead of setting traps.

Smart contracts are like public playgrounds. Don’t leave loose wires sticking out.

5. Storage – Where Every Byte Has Rent

On Polkadot, storage isn’t free. It’s not like your 500GB hard drive at home.
Each piece of data your contract stores costs gas and the bigger your storage, the more expensive your contract gets.

👉 In Rust, you can use all kinds of fancy data structures.
👉 In ink!, you need to be smart and lean.

Use:

Mapping instead of heavy HashMap.
Compact, storage-friendly types.
Careful cloning (remember, copying big stuff is like duplicating a skyscraper it’s expensive.)

The storage you design is like renting space in a premium apartment don’t hoard junk you don’t need.

Final Thoughts

Building on Polkadot is exciting, but it’s a different playground.
If you master these five Rust concepts, you’ll be a few steps ahead of most people stumbling through smart contract development.

👉 You don’t need to be a Rust wizard.
👉 You just need to know what matters.

So go ahead build, test, break things, and fix them. And remember,
Smart contracts don’t need to be smart to everyone. They just need to work.

Quote:

The Rust concepts that challenge you the most are usually the ones that will grow you the fastest

If you found this article interesting, what else would you add? Let me know in the comments.

References

Strategies for Debugging Immutable Code

Cherrypick14 — Sun, 09 Jun 2024 21:10:54 +0000

As any seasoned developer can attest, debugging code can often feel like a never-ending battle against an ever-multiplying army of bugs – a relentless game of whack-a-mole where squashing one issue only seems to spawn two more in its place. In the world of Go programming, immutability is a powerful ally that can make your code more reliable and easier to maintain, but even this helpful tool has its own unique challenges when it comes to debugging.

In Go, you'll find two types of data structures: immutable (value) types and mutable (reference) types. Immutable types, like int, float, bool, string, and good ol' structs without any fancy reference types, are set in stone – they cannot be modified after creation, much like a developer's love for a good cup of coffee. On the other hand, mutable types, such as slices, maps, and channels, can be changed, even though their elements might be immutable or mutable depending on their types, making them as unpredictable as a rubber duck's mood.

Working with immutable data structures can simplify how you think about your program's state and reduce the risk of unintended changes causing bugs. However, even with these benefits, debugging immutable code can present its own unique challenges, like trying to navigate a maze while wearing a blindfold – frustrating, but not impossible with the right strategies.

Immutable data structures, by their very nature, cannot be modified once created, which can make it tricky to observe and manipulate data during the debugging process. It's like trying to catch a glimpse of a shooting star – blink, and you might miss it. Additionally, immutability can introduce new kinds of bugs, such as accidentally creating new copies of data when you intended to modify existing ones, leaving you scratching your head like a confused monkey.

This article aims to equip you with practical strategies and techniques for effectively debugging immutable code in Go. Whether you're working with built-in immutable types or creating your own custom immutable data structures, these strategies will help you identify and resolve issues more efficiently, allowing you to fully harness the power of immutability in your Go projects.

1. Leveraging Logging and Tracing.

One of the most powerful tools for debugging immutable code is effective logging and tracing. By logging relevant information at strategic points in your code, you can gain valuable insights into the state of your program and the flow of data through your immutable data structures.

func processData(data []byte) (result []byte, err error) {
    log.Printf("Processing data: %v", data)
    // ... data processing logic ...
    log.Printf("Result: %v", result)
    return result, nil
}

In the example above, we log the input data and the final result, providing a clear trail of information that can aid in debugging. Additionally, you can employ more advanced logging techniques, such as structured logging or using third-party logging libraries like logrus or zap.

2. Leverage Debuggers and Profilers.

While immutable data structures can simplify debugging by reducing the number of potential sources of mutation, they can also make it more challenging to observe and manipulate data during the debugging process. Fortunately, Go's built-in debugger (dlv) and profiling tools can be invaluable allies in these situations.

func main() {
    data := []byte("hello, world")
    result, err := processData(data)
    if err != nil {
        log.Fatalf("Error processing data: %v", err)
    }
    fmt.Println(string(result))
}

By setting breakpoints and inspecting variables at different points in your code, you can gain insights into the state of your immutable data structures and identify potential issues. Additionally, profiling tools like pprof can help you detect performance bottlenecks, memory leaks, or other issues that may be related to your immutable data structures.

3. Embrace Pure Functions and Immutable Transformations.

Functional programming techniques, such as pure functions and immutable data transformations, can greatly simplify debugging by reducing side effects and making code more predictable. In Go, you can leverage these techniques to work with immutable data structures more effectively.

func transformData(data []byte) []byte {
    // Perform some transformation on the data
    // ...
    return result
}

func processData(data []byte) ([]byte, error) {
    transformed := transformData(data)
    // ... further processing ...
    return result, nil
}

In the example above, transformData is a pure function that takes an immutable slice of bytes as input and returns a new, transformed slice without modifying the original data. transformData is likely a pure function because it consistently returns the same result for the same input and has no side effects while processData is less likely to be a pure function due to error handling and potential side effects from additional processing.By separating your data transformations into pure functions, you can more easily reason about their behavior and identify potential issues.

4. Leverage Third-Party Libraries and Tools.

While Go's standard library provides some immutable data structures (e.g., bytes.Buffer, strings.Builder), there are also several third-party libraries and tools available that can aid in working with immutable data structures and debugging immutable code.

For example, the immutable package (https://github.com/benbjohnson/immutable) provides a collection of immutable data structures, including lists, maps, and sets. Using these data structures can simplify your code and provide additional debugging benefits.

Conclusion

Debugging immutable code in Go requires a combination of effective logging and tracing, leveraging debuggers and profilers, embracing pure functions and immutable transformations, and taking advantage of third-party libraries and tools. By applying these strategies, you can unlock the full potential of immutability in Go, writing more robust and maintainable code while simplifying the debugging process.

Remember, immutability is a powerful tool for reducing bugs and improving code quality, and mastering the art of debugging immutable code can be a game-changer for your Go development workflow. While the strategies discussed in this article can greatly aid in debugging immutable code, it's essential to continually learn and adapt as new techniques and tools emerge.

Demystifying Regex in Go

Cherrypick14 — Sun, 19 May 2024 22:54:19 +0000

Certainly! Regular expressions (regex) in Go can be a powerful tool for pattern matching and text manipulation, but they should be used judiciously and in appropriate scenarios. Here are some points to consider:

When TO use regex in Go:

Validating user input: Regex can be used to validate input strings against specific patterns, such as email addresses, phone numbers, or URLs.
Parsing and extracting data: Regex can help extract specific parts of a string, such as extracting dates, IDs, or keywords from larger texts.
Text manipulation: Regex can be used to perform operations like replacing, splitting, or cleaning text based on patterns.
Log analysis: Regex is useful for parsing and analyzing log files, where patterns need to be identified and extracted.

The example provided falls under the category of "Log analysis": Regex is useful for parsing and analyzing log files, where patterns need to be identified and extracted.

In the given example, we are using a regular expression pattern to parse and extract relevant information (timestamp, severity level, and message) from log entries. This is a typical use case for log analysis, where log files often contain semi-structured or unstructured data that needs to be parsed and processed.

In the above example:

We define a regular expression pattern ^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w+)\] (.*) that captures the timestamp, severity level, and message from the log entry.
The regexp.MustCompile function compiles the regular
expression pattern into a regular expression object.
The FindStringSubmatch method is used to match the pattern against the log entry string.
If a match is found, the captured groups are extracted from the match slice.
The extracted timestamp, severity, and message are printed to the console.
When you run this code with the log entry "2023-05-18 12:35:12 [ERROR] Failed to connect to the database.", the output will be:

This example demonstrates how regular expressions can be used to parse and extract specific pieces of information from semi-structured text data, such as log entries. By defining a suitable pattern, you can capture the desired parts of the text and process them further as needed.

Regular expressions are particularly useful in scenarios where the data format is not strictly defined or follows a loosely structured pattern, making it difficult to use traditional parsing techniques or libraries.

An explanation of the different parts of the regex pattern above.

^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) \[(\w+)\] (.*)

^(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}): This part captures the timestamp in the format "YYYY-MM-DD HH:MM:SS". The parentheses () create a capturing group, which means the matched text will be stored in the result array for later use. The ^ symbol asserts that the match must start at the beginning of the string.
\[(\w+)\]: This part captures the severity level enclosed within square brackets [].
\[ and \] are used to match the literal square bracket characters [ and ].
(\w+) is a capturing group that matches one or more word characters (\w matches letters, digits, or underscores).
(.*): This part captures the remaining text after the severity level, which is the log message itself.
(.*) is a capturing group that matches any character (except newline) zero or more times using the .* pattern.

So, when you break it down:

\[(\w+)\] captures the severity level (e.g., "INFO", "WARNING", "ERROR") inside the square brackets.
(.*) captures the log message that comes after the severity level.

In the example log entry "2023-05-18 12:35:12 [ERROR] Failed to connect to the database.", the regular expression pattern will match as follows:

The first capturing group(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}) will capture "2023-05-18 12:35:12" (the timestamp).

The second capturing group (\w+) inside \[(\w+)\] will capture "ERROR" (the severity level).

The third capturing group (.*) will capture "Failed to connect to the database." (the log message).

These captured groups are stored in the match slice, which you can then access and use in your code:

match := re.FindStringSubmatch(logEntry)

By defining a suitable regular expression pattern, we can identify and extract specific components of the log entries, such as the timestamp, severity level, and message. This allows us to analyze and process the log data more effectively, as we can separate and handle each component individually.

Log analysis is one of the most common and robust use cases for regular expressions because log files frequently exhibit varying formats and patterns, making it challenging to use traditional parsing techniques or libraries. Regular expressions provide the flexibility and power to handle these diverse log formats and extract the desired information.

When NOT to use regex in Go:

When the pattern is simple: For basic string operations like checking if a string starts or ends with a specific substring, using built-in string functions like strings.HasPrefix or strings.HasSuffix is more efficient and readable.
When the pattern is complex: While regex can handle complex patterns, it can become difficult to read and maintain. In such cases, it's better to use dedicated parsing libraries or write custom parsing logic.
When performance is critical: Regex operations can be computationally expensive, especially for complex patterns or large input strings. If performance is a concern, consider alternative approaches or optimize the regex pattern.

Potential alternatives to regex in Go:

String manipulation functions: Go's standard library provides various string functions (strings package) that can handle basic operations without the need for regex.
Dedicated parsing libraries: For specific domains or formats, there may be dedicated parsing libraries that offer a more robust and efficient solution than regex. For example, the net/url package for parsing URLs, or the encoding/json package for parsing JSON data.
Custom parsing logic: Depending on the complexity of the problem, writing custom parsing logic using string operations and control flow statements can be more readable and efficient than regex in some cases.

Tools and utilities for working with regex in Go:

regexp package: Go's standard library includes the regexp package, which provides functionality for working with regular expressions.
Online regex testers and debuggers: Tools like (https://regex101.com/) or (https://regexr.com/) can help you test and debug your regular expressions before integrating them into your Go code.
Regex playground: The Go Playground (https://go.dev/play/) allows you to experiment with regex patterns and Go code interactively.

When using regex in Go, it's important to follow Best Practices:

Use named capturing groups and comments to improve readability.
Test and validate your regex patterns thoroughly.
Consider performance implications, especially for complex patterns or large input strings.
Prefer simple string operations or dedicated parsing libraries when appropriate, as they can be more efficient and maintainable.

By carefully considering the scenarios and weighing the trade-offs, one can effectively leverage the power of regex in Go while maintaining code readability, maintainability, and performance.

How to Pull from a Remote Repository

Cherrypick14 — Wed, 07 Sep 2022 11:49:49 +0000

Suppose you're working on a project with other developers. The first thing to do is to create a repository where all the workflow will take place. Since y'all are gonna contribute to the repo, you have to understand the git tools. Someone from the team has made some changes to the repo, how do you stay updated..? Instead of zipping up files and creating more confusion, all you need to do is pull their changes into your local repository.

How to pull the changes:

Navigate to your Git repo folder in your chosen terminal.
Then run a git pull command.

So git pull is usually a combination of git fetch + git merge
It basically involves fetching upstream changes and syncing them with the local ones.

When should I use git pull?

Before you start working ~ to stay updated with the latest changes.
Before you push anything.

Fetching the Changes:
git fetch gets to download the latest remote repo changes.
git merge now merges those changes into your local codebase.

And what if I want to review the changes first and not merge the code immediately..? ~ Just do a git fetch other than git pull.
You'll get to proceed as per the steps listed in the ~ How to pull the changes. The difference comes in the 2nd part, instead of running a git pull command, run git fetch.

Serving Your Static Files With Express

Cherrypick14 — Sat, 04 Dec 2021 15:16:44 +0000

Getting started with Express

What is Express?

It's basically a web application framework for Node.

First things first. Ensure your node.js env is set up. If not and you are a linux user, you can use a tool called Node Version Manager to help install node on your machine. Note: You should have git and curl installed. To get started with git and curl if at all you don’t have them installed in your system’s package manager. Example on an ubuntu or Debian, one would run

sudo apt-get install curl git

So back to Express. Some of its merits include its flexibility _and _minimality. To get started using Express, you need to use NPM to install the module.

npm install -g express

To get all dependencies that are needed to run the app, you run

npm install

Once you have Express installed and an already existing directory like the one below, you’ll get to see something like this in the package.json file in “dependencies”.

Let's talk about nodemon for a sec:

From the above snip, you guys can note the nodemon in the devdependencies. It’s actually a tool that helps node.js based applications by automatically restarting the node application
when file changes in the directory are spotted. To install nodemon on your project as dev-dependency, just type;

npm install nodemon --save-dev

So to get started on serving your files with Express, make sure you have all your files including the index.html in your public directory.

The files can be served as below:

Incase this doesn’t work out for you, you can try using serve-index. Much is explained in this article. Check it out here:

Opened to any feedback. #Learning never stops

https://medium.com/swlh/serve-directory-listings-in-an-express-app-with-serve-index-ff54f20c9636