• Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.
• \(C = \sum_p(c_pt_p)\): The overall complexity is determined by the complexity of each part \(p\) weighted by the fraction of time developers working on that part.
  • Isolating complexity in a place where it will never be seen is as good as eliminating the complexity.
• Complexity is more apparent to readers than writers: if you write a piece of code that seems simple to you, but others think it is complex, then it is complex.

• Change amplification: a seemingly simple change requires code modifications in many different places.
• Cognitive load: developers have to spend more time learning the required information to complete a task, which leads to greater risk of bugs.
  • E.g., a function allocates memory and returns a pointer to the memory, but assumes the caller should free the memory.
  • Sometimes an approach that requires more lines of code is actually simpler as it reduces cognitive load.
• Unknown unknowns (the worst!): it is not obvious which pieces of code must be modified or which information must have to complete the task.
• The goal of a good design is for a system to be obvious: a developer can make a quick guess about what to do and yet to be confident that the guess is correct.

• Complexity is caused by two things: dependencies and obscurity.
• A dependency exists when a code cannot be understood and modified in isolation.
  • E.g., in network protocols both senders and receivers must conform to the protocol, changing code for the sender almost always requires corresponding changes at the receiver.
  • Dependencies are fundamental and cannot be completely eliminated, the goal is to make the dependencies remain simple and obvious (e.g., variable renaming are detected by compilers).
• Obscurity occurs when important information is not obvious, e.g., a variable is too generic or the documentation is inadequate.
  • Obscurity is often associated with non-obvious dependencies.
  • Inconsistency is also a major contributor, e.g., the same variable name is used for two different purposes.
  • The need for extensive documentation is often a red flag that the design is complex.
• Dependencies lead to change amplification and cognitive load; obscurity creates unknown unknowns and cognitive load.

• Requires an investment mindset to improve the system design rather than taking the fastest path to finish the current task.
• Proactive investment: try a couple of alternative designs and pick the cleanest one; imagine a few ways in which the system might need to be changed in the future; write documentation.
• Reactive investments: continuously make small improvements to the system design when a design problem becomes obvious rather than patching around it.
• The ideal design tends to emerge in bits and pieces, thus the best approach is to make lots of small investments on a continual basis, e.g., 10-20% of total development time on investments.

• A module interface contains two information: formal and informal.
• The formal part for a method is its signature; The formal interface for a class consists of the signatures for all public methods and variables.
• The informal part includes its high-level behavior and usage constraints; they can only be described using comments and cannot be ensured by the programming languages.
  • Informal aspects are larger and more complex than the formal aspects for most interfaces.
• While providing choice is good, interfaces should be designed to make the common case as simple as possible (c.f. \(C = \sum_p(c_pt_p)\)).

• An abstraction is a simplified view of an entity, which omits unimportant details.
  • The more unimportant details that are omitted from an abstraction, the better, otherwise the abstraction increases the cognitive load.
  • A detail can only be omitted if it is unimportant, otherwise obscurity occurs.
• In modular programming, each module provides an abstraction in form of its interface.
• The key to designing abstractions is to understand what is important.
  • E.g., how to choose storage blocks for a file is unimportant to users, but the rules for flushing data to secondary storage is important for databases, hence it must be visible in the file system interface.
  • Garbage collectors in Go and Java do not have interface at all.

• The leakage occurs when a design decision is reflected in multiple modules. thus creating dependencies between the modules.
  • Interface information is by definition has been leaked.
• Information can be leaked even if it does not appear in the interface, i.e., back-door leakage.
  • E.g., two classes read and write the same file format, then if the format changes, both classes need to be modified; such leakage is more pernicious than interface leakage as it is not obvious.
• If affected classes are relatively small and closely tied to the leaked information, they may need to be merged into a single class.
  • The bigger class is deeper as the entire computation is easier to be abstracted in the interface compared to separate sub-computations.
• One may also pull the leaked information out of all affected classes and create a new class to encapsulate the information, i.e., replace back-door leakage with interface leakage.
• One should avoid exposing internal data structures (e.g., return by reference) as such approach makes more work for callers, and make the module shallow.
  • E.g., instead of writing getParams() which returns a map of all parameters, one should have getParameter(String name) and getIntParameter(String name) to return a specific parameter and throw an exception if the name does not exist or cannot be converted.

• Temporal decomposition is a common cause of information leakage.
• It decompose the system into operations corresponding to the execution order.
  • E.g., A file-reading application is broken into 3 classes: read, modify and write, then both reading and writing steps have knowledge about the file format.
  • The solution is to combine the core mechanisms for reading and writing into a single class.
• Orders should not be reflected in the module structure unless different stages use totally different information.
• One should focus on the knowledge needed to perform each task, not the order in which tasks occur.

• Specialized design: use individual method in the text class to support each high-level features, e.g., backspace(Cursor cursor) deletes the character before the cursor; delete(Cursor cursor) deletes the character after the cursor; deleteSelection(Selection selection) deletes the selected section.
• The specialized design creates a high cognitive load for the UI developers: the implementation ends up with a large number of shallow methods so a UI developer had to learn all of them.
  • E.g., backspace provides a false abstraction as it does not hide the information about which character to delete.
• The specialized design also creates information leakage: abstractions related to the UI such as backspace key and selection, are reflected in the text class, increasing the cognitive load for the text class developers.
• General-purpose design define API only in terms of basic text features without reflecting the higher-level operations.
  • Only three methods are needed to modify a text: insert(Position position, String newText), delete(Position start, Position end) and changePosition(Position position, int numChars).
    • The new API uses a more generic Position to replace a specific user interface Cursor.
    • The delete key can be implemented as text.delete(cursor, text.ChangePosition(cursor, 1)), the backspace key can be implemented as text.delete(cursor, text.ChangePosition(cursor, -1)).
• The new design is more obvious, e.g., the UI developer knows which character to delete from the interface, and also has less code overall.
• The general-purpose methods can also be used for new feature, e.g., search and replace text.

• A pass-through method is a method that does little except invoke another method, whose signature is similar or identical to the callee function.
• Pass-through methods usually indicates there is not a clean division of responsibility between classes.
• Pass-through methods also create dependencies between classes.
• The solution is to refactor the classes, e.g., expose the lower level class directly to the higher level (b), redistribute the functionality (c) or merge them (d):

• A pass-through variable is a variable that is passed down through a long chain of methods.
• Pass-through variables add complexity as all intermediate methods must be aware of the existence and need to be modified when a new variable is used.
• The author’s solution is to introduce a context object which stores all application’s global states, e.g., configuration options and timeout value, and there is one context object per system instance.
• To avoid passing through the context variable, a reference to the context can be saved in other objects.
  • When a new object is created, the context reference is passed to the constructor.
• Contexts should be immutable to avoid thread-safety issues and may create non-obvious dependencies.

• Dispatcher: a method that uses its arguments to select a specific method to invoke and passes most of its arguments.
  • E.g., when a web server receives an HTTP request, it invokes a dispatcher to examine the URL and selects a specific method to handle the request.
• Polymorphous methods, e.g., len(string) and len(array) reduces cognitive load; they are usally in the same layer and do not invoke each other.
• Decorator: a wrapper that takes an existing object and extends its functionality.
• Decorators are often shallow and contain pass-through methods, one should consider following alternatives before using them:
  • Add the new functionality directly to the class if it is relatively general-purpose; or merge it with the specific use case if it is specialized.
  • Merge the new functionality with an existing decorator to make the existing decorator deeper.
  • Implement it as a stand-alone class independent of the base class, e.g., Window and ScrollableWindow.

• Example 1: instead of throwing an exception when a key does not exist in remove, simply return to ensure the key no longer exists.
• Example 2: instead of throwing an exception when trying to delete a file that is still open in other processes, mark the file for deletion to deny any processes open the old file later, and delete the file after all processed have closed the file.
• Example 3: instead of throwing an IndexOutOfBoundsExeception when substring(s, begin, end) takes out-of-range arguments, return the overlap substring.

• An exceptional condition is detected and handled at a low level in the system so that higher levels need not be aware of the condition.
• E.g., when a TCP packet is lost, the packet is resent within the implementation and clients are unaware of the dropped packets (they notice the hanging and can abort manually).
• Exception masking results in deeper classes and pulls complexity downward.

• Exception aggregation handles many special-purpose exceptions with a single general-purpose handler.
• Example 1: instead of catching the exception for each individual missing parameter, let the single top-level exception handler aggregate the error message with a single top-level try-catch block.
  • The top-level handler encapsulates knowledge about how to generate error responses, but knows nothing about specific errors.
  • Each service knows how to generate errors, but does not know how to send the response.
• Example 2: promote rare exceptions (e.g., corrupted files) to more common exceptions (e.g., server crashes) so that the same handler can be used.

• The correct process of writing comments will improve the system design.
• A significant amount of design information that was in the mind of the designer cannot be represented in code, e.g., the high-level description of a method, the motivation for a particular design.
• Comments are fundamental to abstractions: if users must read the code to use it, then there is no abstraction.
  • If there is no comment, the only abstraction of a method is its declaration which misses too much essential information to provide a useful abstraction by itself; e.g., whether end is inclusive.
• Good comments reduce cognitive load and unknown unknowns.

• Follow the comment conventions, e.g., Doxygen for C++, godoc for Go.
• Comments categories:
  • Interface: a comment block that precedes the declaration; describes the interface, e.g., overall behavior or abstraction, arguments, return values, side effects or exceptions and any requirements the caller must satisfy.
  • Data structure member: a comment next to the declaration of a field in a data structure, e.g., a variable.
  • Implementation comment: a comment inside the code to describe how the code work internally.
  • Cross-module comment: a comment describing dependencies that cross module boundaries.
• The interface and the data structure member comments are the most important and should be always present.
• Don’t repeat the code: if someone who has never seen the code can also write the comment by just looking at the code next to the comment, then the comment has no value.
• Don’t use the same words in the comment that appear in the name of the entity being described, pick words that provide additional information.
• Comments should augment the code by providing information at a different level of detail.
  • Lower-level: add precision by clarifying the exact meaning of the code.
  • Higher-level: offer intuition behind the code.

• Vague name examples: “count”, “status”, “x”, “result” in a no return method.
• It’s fine to use generic “i/j” in a loop as long as the loop does not span large.
• A name may also become too specific, e.g., delete(Range Selection) suggests the argument must be a selection, but it can also be passed with unselected range.
• If you find it difficult to come up with a name that is precise, intuitive and not too long, then it is a red flag that the variable may not have a clear design.
  • Consider alternative factorings, e.g., separate the representation into multiple variables.

• Always use the common name for and only for the given purpose, e.g., ch for a channel.
• Make sure the purpose is narrow enough that all variables with the same name have the same behavior.
  • E.g., a block purpose is not narrow as it can have different behaviors for physical and logical blocks.
• When you need multiple variables that refer to the same general thing, use the common name for each variable and add a distinguishing prefix, e.g., srcBlock and dstBlock.
• Always use i in outmost loops and j for nested loops.

• Secure, reliable and scalable.
• Scalability relies on the network message distribution efficiency; hence the IC network is divided into subnets.

• From top to down: execution, message routing, consensus, P2P.

• Enables nodes to synchronize the replicated state of the subnet by downloading the required state and verify its authenticity relative to the subnet’s chain key with the state sync protocol.
• Up-to-date nodes create a checkpoint regularly by writing the replicated state to disk, computing the state hash, the consensus layer tries to agree on the state by including the hash in the catch-up packages (CUPs).
  • A state recorded on the CUP implies the majority of nodes agree on the state and a majority of nodes can serve this state.

• A new transport protocol with TLS 1.3, new handshake, new packet structure, encryption, uni/bi-directional streams, etc.
• Low latency: zero-handshake latency for recently visited sites, no head-of-line (HOL) blocking.
  • HOL blocking: the delivery of subsequent packets in a data stream is delayed due to the need to process or retransmit an earlier packet.
• Encrypted transport: encrypt most of the packet header by using the connection IDs.
  • The connection IDs also tracks migrated connections securely.
  • Packet numbers are also encrypted to avoid cross-network correlation.
• Packetization: support multiple stream frames in a single packet.
  • Allow unaffected streams to continue processing even if one stream has packet loss.
  • Enable multiplexing of different data streams over a single connection.
• Stateless design: each QUIC packets contain enough information to be processed independently and has built-in mechanism to match responses to requests.

• If the receiver slows down the message consumption, the sender’s buffer fills up and the sender’s networking layer must take one of the three paths:
  • Propagate the backpressure to the application layer to slow down data production; would be a DoS attack vector.
  • Buffer messages (indefinitely); also an attack vector.
  • Drop egress messages; risks the liveness, i.e., no delivery guarantee.

• When a subnet node creates an artifact or receives it from its peer, it gossips this artifact to all its peers, i.e., other connected subnet nodes.
  • Each artifact eventually propagates through the whole subnet.

• Network messages to be broadcast in the subnet, e.g.,
  • Users input to canister smart contracts;
  • Protocol-originating messages, e.g., blocks produced by the consensus layer or state synchronization certification.

• P2P layer should provide the above guarantee under the following constraints:
  • Bounded-time delivery or eventual (under weaker assumptions) delivery.
  • Tolerate up to a certain threshold of dropped artifacts or byzantine nodes (1/3).
  • Each peer has its own share of the resources available at other peers and the resource usage by each peer is bounded.
  • Should be able to prioritize different artifacts.
  • Provide high throughput (rather than low latency) and avoid data duplication to utilize the network.
  • Resilient to DoS/Spam and enable encryption, authenticity and integrity.

• Simply flooding all artifacts consumes unnecessary network bandwidth, instead artifacts previews called adverts are sent first.
• An advert includes fields used by the gossip protocol and its application components (which process the messages) for integrity verification and decision-making (e.g., which artifacts to prioritize)
• Other nodes may request the corresponding artifact from one or more of its peers who send the adverts.
• In the new P2P layer, if the artifact is small enough (< 1KB), adverts are not used.

• A data structure maintained by the gossip protocol.
• Contain all available artifacts for each application component.
• P2P informs consensus and other client components about the pool changes by calling on_state_change(), each component determines its next action, e.g., validation.
  • Each call returns a set of ChangeActions corresponding to the addition and deletion of artifacts from the validated pool of a client; the corresponding adverts are then broadcasted.
• The artifacts can be persistent to non-volatile storage.
• Separated into validated and unvalidated sections; the size of each unvalidated section for each peer is bounded to prevent bad peers from filling up the pool.

• Advert queue: a priority queue of all adverts the peer has received from another peer, ordered by their priority.
• Requested set: contains all adverts whose artifacts have been requested.
• Received check cache: used to prevent duplicated artifact requests.

• Create a new advert for a new artifact added by application component locally and sends to all peers;
• Process a new advert.
• Process a new artifact.
• Handle recovery and reconnection.

• NNS manages the subnet membership, each node only requests and accepts connections with nodes in the same subnet to prevent DoS attack.
• NNS canisters guarantee that all communication between two nodes are encrypted and authenticated by TLS.

• Transport keeps buffering ongoing messages in TX queues;
• When the connection works again, transmit all buffered messages and empty TX queues.

• Transport notifies the receiver gossip protocol, sends retransmission request with artifact filter to tell the sender the latest advert the receiver has seen;
  • The receiver may not need to catch up all artifacts since they may have received the same adverts from other peers before sending the retransmission.
• When receiving a retransmission request, the sender sends all relevant adverts according to the filter through the TX queue.
• If the TX queue becomes full again, another retransmission takes place.

• P2P layer is designed to distribute small messages, which is not the case for the state sync protocol.
• To simplify the P2P layer, it is separated into 2: one for state sync and the other for the rest clients.
• The P2P layer uses a new transport component to support two async APIs: push(message, peer_id) and rpc(message, peer_id) -> response.
  • P2P periodically calls push() with the current states to advertise own current state to all peers.
  • When noticing itself is behind, it calls rpc() to request specific chunks
• Using a single TCP steam is impossible to relate requests to responses without tracking states, therefore QUIC protocol is used to multiplex multiple streams in one connection.
  • P2P layer can be completely asynchronous to better utilize CPU and bandwidth resources, e.g., congestion on state synchronization does not necessarily affect other adverts.
  • Every response is tied to a corresponding request without having to maintain states.
  • Can help dynamically prioritize traffic of different clients.

• Bounded number of active artifacts in the validated artifact pool; the consensus protocol uses checkpoints to purge artifacts periodically, hence a maximal pool size \(C\).
• Explicit expiry of artifacts; if an artifact is purged from a pool, it is no longer disseminated to peers; if no peer of a node has an artifact, the node is guaranteed to not need that artifact even if it failed to receive it.
  • During state synchronization, nodes use artifacts to update own states, once states are updated, artifacts can be safely purged after some time, e.g., to help other nodes to synchronize states.
  • Newly joined nodes use CUP for offline state sync.

• Maintained on the sender side and inferred on the receiver side.
• The table size corresponds to the number of active artifacts in the validated pool.
• Whenever an artifact is added to the validated pool, it is added in the slot table on the sender side.
  • The sender sends out a slot update message to all peers.
  • Receivers infer the slot table state based on the arrived slot update messages.
  • Deletions are implicitly propagated by new artifact reusing the slot.
  • Allows nodes to notice when an artifact no longer exists in any peer’s slot tables and can remove it from the unvalidated pool.
• Each slot maintains a version number for the slot artifact; receivers only accept update messages with higher version numbers than the one it already has.
• A lightweight thread is spawn for each slot per peer to reliably push the slot update message.
• The approach combines buffering messages and dropping messages in handling the backpressure to achieve resilience and liveness.
• Bounds on the unvalidated pool: \(C\) artifacts from an honest peer and \(2C\) from a malicious peer.

On a local machine, it’s pretty straightforward. You just grab a scraper library like go-rod and figure out the right API calls. After you’ve snagged the page, you can use an HTML parser like goquery to pull out all the menus.

The only snag with go-rod is it’s too bulky for a Render free account. It needs to install Chromium first, but Render’s 512M RAM can’t handle that. I didn’t want to hunt for another free host, so go-rod had to go.

Claude then pitched the idea of online scraping services. Most I found were expensive, aimed at heavy-duty scraping. But I lucked out with AbstractAPI, offering 1000 total requests for free. If I’m smart, that could last me about half a year. ScraperAPI seemed promising with 1000 monthly free requests. But it choked on Javascript rendering for my targeted pages even with render=true.

AbstractAPI has its quirks too. The scraped result comes out messy, full of \n and \&#34. So I had to clean it up before goquery can make sense of it.

• Define a link node:

  struct Node {
    // member initializer list, e.g., next_(nullptr) equals to next_ = nullptr
    Node(int val) : next_(nullptr), prev_(nullptr), value_(val) {}
  
    Node *next_;
    Node *prev_;
    int value_;
  };
  

• Define the iterator for the DLL:

  class DLLIterator {
  public:
    // takes in a node to mark the start of the iteration
    DLLIterator(Node *head) : curr_(head) {}
  
    // prefix increment operator (++iter)
    DLLIterator &operator++() {
      // must use -> to access the member of a pointer!
      // use . if accessing the object itself
      curr_ = curr_->next_;
      return *this;
    }
  
    // postfix increment operator (iter++)
    // the (int) is a dummy parameter to differentiate
    // the prefix and postfix increment
    DLLIterator operator++(int) {
      DLLIterator temp = *this;
      // this is a pointer to the current object
      // *this returns the iterator object
      // ++*this calls the prefix increment operator,
      // which equals to `this->operator++()`
      ++*this;
      return temp;
    }
  
    // implement the equality operator
    // an lvalue reference argument avoids the copy
    // the const in the parameter means this function
    // cannot modify the argument
    // the `const` outside the parameter list means
    // the function cannot modify `this`
    bool operator==(const DLLIterator &str) const {
      return itr.curr_ == this->curr_;
    }
  
    // implement the dereference operator to return the value
    // at the current iterator position
    int operator*() { return curr_->value_; }
  
  private:
    Node *curr_;
  };
  

• Define DLL:

  class DLL {
  public:
    DLL() : head_(nullptr), size_(0) {}
  
    // the destructor deletes nodes one by one
    ~DLL() {
      Node *current = head_;
      while (current != nullptr) {
        Node *next = current->next_;
        delete current;
        current = next;
      }
      head_ = nullptr;
    }
  
    // after the insertion `new_node` becomes the new head
    // `head` is just a pointer to the node
    void InsertAtHead(int val) {
      Node *new_node = new Node(val);
      // new_node->next points to the object pointed by head_
      new_node->next_ = head_;
  
      if (head_ != nullptr) {
        head_->prev_ = new_node;
      }
  
      head_ = new_node;
      size_ += 1;
    }
  
    DLLIterator Begin() { return DLLIterator(head_); }
  
    // returns the pointer pointing one after the last element
    // used in the loop to determine whether the iteration ends
    // e.g., `for (DLLIterator iter = dll.Begin(); iter != dll.End(); ++iter)`
    DLLIterator End() { return DLLIterator(nullptr); }
  
    Node *head_{nullptr};  // in-class initializers
    size_t size_;
  };
  

#include <iostream>
#include <memory>  // to use std::unique_ptr
#include <utility> // to use std::move

// class Point is the same as before

// takes in a unique point reference and changes its x value
void SetXTo10(std::unique_ptr<Point> &ptr) { ptr->SetX(10); }
int main() {
  // initialize an empty unique pointer
  std::unique_ptr<Point> u1;
  // initialize a unique pointer with constructors
  std::unique_ptr<Point> u2 = std::make_unique<Point>();
  std::unique_ptr<Point> u3 = std::make_unique<Point>(2, 3);
  // can treat a unique pointer as a boolean to determine whether
  // the pointer contains data
  std::cout << "Pointer u1 is " << (u1 ? "not empty" : "empty") << std::endl;
  if (u2) {
    std::cout << u2->GetX() << std::endl;
  }
  // unique_ptr has no copy constructor!
  std::unique_ptr<Point> u4 = u3; // won't compile!
  // can transfer ownership with std::move
  std::unique_ptr<Point> u5 = std::move(u3); // then u3 becomes empty!
  // pass the pointer as a reference so the ownership does not change
  SetXTo10(u5); // can still access u5 afterwards
  return 0;
}

• Note that the compiler does not prevent 2 unique pointers from pointing to the same object.

// the following code can compile
// but it causes a double deletion!
MyClass *obj = new MyClass();
std::unique_ptr<MyClass> ptr1(obj);
std::unique_ptr<MyClass> ptr2(obj);

• A mutex wrapper that provides a RAII-style of obtaining and releasing the lock.
• When the object is constructed, the locks are acquired; when the object is destructured, the locks are released.
• Better than std::mutex since it provides exception safety.

#include <iostream>
#include <mutex>

int count = 0;
std::mutex m;
void add_count() {
  // the scoped_lock constructor allows for the thread
  // to acquire the mutex m
  std::scoped_lock slk(m);
  count += 1;
  // once the function finishes, slk is destructurd and
  // m is released
}

• Allow threads to wait until a particular condition before acquiring a mutex.
• Allow other threads to signal waiting threads to alert them that the condition may be true. notify_one

#include <condition_variable>
#include <iostream>
#include <mutex>
#include <thread>

int count = 0;
std::mutex m;
// declare a condition variable
std::condition_variable cv;
void add_count_and_notify() {
  std::scoped_lock slk(m);
  count += 1;
  if (count == 2) {
    // notidy one waiting thread
    // otherwise the waiter thread hangs forever
    cv.notify_one();
  }
}
void waiter_thread() {
  // a unique_lock is movable but not copiable
  // more flexible than scoped_lock as it can unlock
  // and relock manually, while scoped_lock can only be
  // unlocked automatically.
  // scoped_lock cannot be used with condition variables
  std::unique_lock lk(m);
  cv.wait(lk, [] { return count == 2; });
  std::cout << count << std::endl;
}
int main() {
  std::thread t1(waiter_thread);
  // make t1 really waits
  std::this_thread::sleep_for(std::chrono::milliseconds(100));
  std::thread t2(add_count_and_notify);
  std::thread t3(add_count_and_notify);
  t1.join();
  t2.join();
  t3.join();
  return 0;
}

• A reader-writer lock allows multiple threads to have shared read access (no writers are allowed during read operations) and exclusive write access, i.e., no other readers or writers are allowed during the write.
• C++ does not have a specific reader-writer’s lock library, but can be emulated with std::shared_mutex, std::shared_lock and std::unique_lock.
• std::shared_mutex is a mutex that allows for both shared read-only locking and exclusive write-only locking.
• std::shared_lock can be used as an RAII-style read lock.

• std::unique_lock can be used a RAII-style exclusive write lock.

  #include <iostream>
  #include <mutex>
  #include <shared_mutex>
  #include <thread>
  
  int count = 0; // resource
  std::shared_mutex m;
  void read_value() {
    // use shared_lock to gain read-only, shared access
    std::shared_lock lk(m);
    std::cout << "Reading " + std::to_string(count) << std::endl;
  }
  
  void write_value() {
    // use unique_lock to gain exclusive access
    std::unique_lock lk(m);
    count += 3;
  }
  int main() {
    // since all 3 threads run in parallel,
    // the output is not deterministic
    std::thread t1(read_value);
    std::thread t2(write_value);
    std::thread t3(read_value);
    t1.join();
    t2.join();
    t3.join();
    return 0;
  }
  

A sticker tag bot needs two main functionalities:

• Handle direct messages to add new sticker tags.
• Handle inline queries to search for stickers using a given tag.

To implement the first functionality, I created a simple state machine with two states:

1. The initial state waits for a sticker input and then moves to the tag state.
2. The tag state waits for any text input to use as the tag for the previous sticker.

To implement the second functionality, one needs to use the InlineQueryResultCachedSticker method.

For local testing, one can use a lightweight local key-value storage to store and search sticker tags. I used BadgerDB(Golang) for example.

I noticed that the generated file ID for the same sticker is different each time, making it hard to check for duplicates when adding new tags. To address this, I added a /delete method to remove tags when needed.

I couldn’t find an official way to make a bot visible only to me. Suggested by Claude, I predefined a list of authorized users. Then I performed a sanity check before handling any messages.