Skip to content

Instantly share code, notes, and snippets.

View de-sh's full-sized avatar
🦀
Rustacean from Kerala

Devdutt Shenoi de-sh

🦀
Rustacean from Kerala
View GitHub Profile
@de-sh
de-sh / vd.rs
Created November 23, 2023 05:52
Vehicle Dynamics, a rust library
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)]
@de-sh
de-sh / incentives.md
Created November 18, 2023 17:29
Greed is in optimization, dynamically incentivise to channel the greed for better

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.

@de-sh
de-sh / keralajs.md
Created March 25, 2023 09:47
Talk at Kerala JS meetup on rust in web-development
@de-sh
de-sh / delay_queue.md
Last active January 9, 2023 18:35
Documenting the analogy I used during a Kerala Rustaceans meetup to explain my use of DelayQueue

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:

  1. The bus starts the moment there is one rider, or
  2. 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

@de-sh
de-sh / Dockerfile
Created November 20, 2022 16:45
Container used to build uplink for Android targets
FROM rust
COPY ./setup.sh .
RUN ./setup.sh
@de-sh
de-sh / monkey-door.md
Last active October 19, 2022 12:48
A rusty loop based solution to a problem found in the wild

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];
@de-sh
de-sh / systems-cmd-framework.md
Last active September 18, 2022 17:22
Drawing an analogy from software, I try to explain my hypothesis that all systems follow the CMD framework

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

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/"])?;
@de-sh
de-sh / contribution_checklist.md
Last active June 16, 2022 15:18
A list of action items to be performed before opening a PR on your favourite rust project
  • 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.

@de-sh
de-sh / brag.md
Last active April 12, 2022 18:52
A list of work achievements I have been able to make at bytebeam.io
  • Coded the multi-tenancy feature for the bytebeam broker, worked a lot with TLS to implement this. Had my first experience of translating code into a system design and then figuring out changes to ensure the feature had no unforeseen traps during regular use.
  • Designed and implemented a method for achieving ACID like features while working with received commands on a device at the edge, using uplink.
  • Added multiple other features for uplink, including the ability to download and store OTAs when associated command is received.
  • Coded an interface with a dynamically loaded rust binary for Java code, ensuring the ability to configure and operate the binary remained very well accessible for an android application. This culminated in the creation of uplink-android.
  • Mentored members of the team working on rust-lang projects.
  • Maintained multiple opensource projects including rumqtt