Devdutt Shenoi de-sh

Problem Statement

Parseable is experiencing data loss due to a time skew in local-sync. The scheduler operates on minute-based(eventually configurable) intervals and performs flush operations at the end of each interval. However, a timing discrepancy causes late-arriving data to be appended after EOF markers, rendering this data kinda invisible to readers.

Current System Behavior

The scheduler triggers a flush operation at the end of each minute interval

The flush operation:

Writes all in-memory buffered data to disk
Appends an EOF marker to signal completion

All systems tend to collapse, it is the order of nature after all. Greed is but a side effect of a collapsing system, one where ethics, i.e. rules and regulations are lax and the optimizations are focused on variables that are sometimes unimportant to the larger picture. This is not only because we as humans can't agree on infallible laws, but because the agreements themselves have an expiry period while the laws might not.

Some of society's biggest mistakes have been in holding onto traditions and constructs that have affected it's ability to accept the realities of the times. What gibberish? Well, that is exactly what we see on a day to day, in how the herd tends to treat the "pioneers"/"witches". More than enough times, the innovators and radicals have given more to human progress and quality of life than what a few bad actors could have taken away.

Take some time to understand these points and you will notice that quite often the answer to solving for greed is only in using it to our own advantage, i.e.

3 ways in which rust is impacting web development

Rust is being used to replace C++ on the browser, Firefox gecko.
Rust is being used to replace everything on the backend, deno, axum, Next.js compiler, SWC etc.
Rust is taking over jobs on the front-end, rust-wasm, yew, etc.

What are we going to explore today? How I built a QR code generator with rust-wasm.

The Problem

Think of a Bus travelling between two stops, waiting at the first, there are two naive approaches for the driver to decide on when to start the journey:

The bus starts the moment there is one rider, or
When it is full.

While in case 1, the passenger does not have to wait, buses are plying at too high a frequency and there is very low occupancy. Consider these buses as network traffic and you see how very high frequency of network traffic might be a problem.

The problem with case 2 though is that depending on the size of bus and other factors, the first passenger to board bus has to wait for the last vacant seat to also be filled before the bus departs, and sometimes the bus may just be left hanging when no such passenger ever decides to take the bus. This may lead to data loss when considering the network equivalent of the problem, as the bus is stranded at the stop for ever.

Case 2 also happens to be status quo, how we were handling batching in uplink. Each batch would wait to get

Consider the following problem statement:

There are a 100 monkeys, each has a key that can open or close 100 doors. The monkeys come in sequence from 1 to 100 and open or close doors with numbers from their respective sequence number's multiplication table. i.e. monkey #2 can open all even numbered doors while monkey #50 can open only the doors numbered 50 and 100.

What are the doors left opened after all monkeys have done their monkey business?

Solution: Idea: Door i will be open if the number of factors to i are odd, else it will be closed. Since there are only 100 doors to check and we have to check all doors, a nested loop will be a very effective solution:

let mut doors = [false; 100];

The CMD framework for keeping Systems relevant

As is common knowledge, the main dieties in 'Hindu' philosophy/religion are Brahma, Vishnu, and Maheswara, namely the Creator, Maintainer, and Destroyer.

How do they relate to systems? Well, all systems have to go through the cycles that are creation, maintenance, and destruction, no matter how long lived and endless we believe something is, it's just in its own lifecycle. Since I happen to be from the software background, let me frame this explanation in terms of software systems, but hopefully things make sense to everyone reading.

A system obviously requires a creator, that is non-negotiable, but this Brahma could be an independent developer or a large team. No matter the creator, things usually only start coming into place as there are users to provide feedback and it usually takes multiple iterations for a system to get to a stable state. Genesis might be a long journey, and sometimes it is a simple change, either from within or from outside, that creat

Run rust's code formatter cargo fmt.
Run clippy cargo clippy.
Run test suite cargo test.
Does the proposed change behave as expected?
Document how the changes affect the previously known behaviour of the component/product.

Some of this might be a bit boring to repeat, so I wrote a shell script.

	use std::{default, f64::consts::PI};

	use rand::{thread_rng, Rng};

	const BASE_RPM: f64 = 750.0;
	const MAX_RPM: f64 = 5000.0;
	const WHEEL_RADIUS: f64 = 0.4; // in m
	const WHEEL_CIRCUMFERENCE: f64 = 2.0 * PI * WHEEL_RADIUS; // in m

	#[derive(Debug, Default)]

	use std::{env, path::PathBuf};

	fn main() -> Result<(), Box<dyn std::error::Error>> {
	let mut config = prost_build::Config::new();
	config.file_descriptor_set_path(
	PathBuf::from(env::var("OUT_DIR").expect("OUT_DIR environment variable not set"))
	.join("file_descriptor_set.bin"),
	);
	config.compile_protos(&["src/example.proto"], &["src/"])?;

	FROM rust

	COPY ./setup.sh .
	RUN ./setup.sh