de-sh

Java is not something I am very happy about working with, personal dislike aside, I have had a lot of peers discourage me from working with it. But when it comes to interesting technical challenges, it is always a good idea to atleast give it a try. Now that I am at a point where I have spent close to a month on the task, I feel I am more than enough experienced to give my first impressions and more importantly a note of caution to folks who might be considering jumping into the depths, in search of an adventure.

JNI is complex, but it isn't like you have to deal with a lot of the complexity yourself. If you have the advantage of being able to use a simple, yet awesome developer tool called flapigen, you are already off to the races! Yes, I had tried writing the bindings myself, but it wasn't a very good idea, the ability to write code with a DSL and have it generate the bindings is as miracle cure to some of the worst problems a maintainer can face. Flapigen giv

de-sh

• 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

de-sh

• 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

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

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

de-sh

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

FROM rust

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

de-sh

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

3 ways in which rust is impacting web development

1. Rust is being used to replace C++ on the browser, Firefox gecko.
2. Rust is being used to replace everything on the backend, deno, axum, Next.js compiler, SWC etc.
3. 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.

de-sh

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.