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

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

import csv

shares = {} # Per share/scrip info
holding = {} # Held share
bought = {} # Purshased shares to date
sold = {} # Sold shares to date

with open('tradebook.csv') as csvfile:
    for row in csv.reader(csvfile):
        scrip, nos, price, date = row[0], float(row[7]), float(row[8]), row[2]

de-sh

I wrote my first few lines of async rust at the end of 2020, that was the first time I was actually learning about the core principles behind async/await, even thought I have had prior experience writing code with similar keywords in javascript and python, thoug they didn't make much sense then, it was just what I had to write to get through implementing something in my code. Having been pulled into the async world while writing network facing code, I found it to be a learning that also transfered well into college as we were learning about similar stuff in a class on Programming Paradigmns.

The journey into async-rust started for me with some exposure through a well written tutorial on the tokio project's website, which introduced the why in such a way that async/await totally made sense. This piece is a recollection of material that I've used to make sense of and interpret the crazy complex world of async/await over the past year or so. Anyways, if you are new and only ge

de-sh

At the end of 2020 I had learnt a lot about programming in rust-lang and had worked on some large codebases, all while doing some interesting system implementations on the side. We had planned to implement our thesis project by the end of the academic year, but faced a lot of challenges in getting started, procrastination had hit us hard. By January I felt we had done enough experimentation and that we needed to do some "real" work, and hence got started on implementing a core piece of the puzzle, the partially distributed datastore, which consisted of a central server and multiple clients with the ability to cache values and check if invalidated.

To do this, I had to learn gRPC, for which I figured out Tonic would be a great place to start with, and thus, with the code that @bkp31415 had written in proto3, I got started implementing what would be [the first iteration of dstore's gRPC API](https://github.com/vyuham/dstore/commit/727d56de805

de-sh

The problem stated that we need to find the Egyptian fraction sequence given the numerator and denomintor. So I started out with a simple python psuedo code implementation:

ef = []
while nr != 0:
    x = ceil(dr/nr)
    ef += [x]
    # Update remainder values of numerator and denominator
    nr *= x
    nr -= dr
    dr *= x

de-sh

August 16th - 24th: The final week of coding was focused mostly on solving the issues that were found in the linking process that was blocking the test stage. Please refer to the report for week eleven for further details on what conspired in this week.

Update: the issues still persists to the day of work product submission. Yi and I have decided to submit despite a completely working product not having been created from the project due to adverse circumstances. I believe that the main achievement of the task was the formulation of a path that can be followed to fulfill the goal of linking and utilising cloud features for storage within the TiKV server at a later stage.

de-sh

August 2nd - 8th : Yi directed me to document the observable performance metrics of AWS S3 using the fio utility. I have converted the logs that were output by fio into the following gist:

• AWS S3 random-read performance with block_size equal to 4k, 8k, 16k, up to 1M.
• AWS S3 sequential-write performance for block_size=1M , with number of concurrent jobs 1,2,4 and 8.

Most of the rest of this week went into crafring a TiKV config file that can be used with S3, one must be able to make the convenient addition of the following configurations to their regular TiKV config to access the feature on a build that has cloud enabled for engine_rocksdb:

[rocksdb.s3]
enabled = true
src-cloud-bucket = "{aws_bucket_name}"
src-cloud-object = "{aws_object_name}"

de-sh

August 9th - 15th: While working on using our self compiled TiKV server with the TiUP utility, it was found out that the TiKV server was unable to compile properly with AWS support, as the USE_AWS=1 definition wasn't being set properly. The solution to the problem lied in moving this step down line to the librocksdb_cloud_sys/CMakeLists.txt from the associated build.rs file. It was also learnt from this that various code components of rocksdb-cloud/cloud weren't properly written and thus had to be bug fixed. Two PRs as follows were opened to do the same:

• tikv/rocskdb#186
• tikv/rocskdb#188

Associated fixes to rust-rocksdb are also made through tikv/rust-rocksdb#529 and have been set to WIP as they require a solution to the linking problem we are facing with the AWS-CPP-SDK. If you have a solution to the problem, or would like

de-sh

def is_prime(n):
    if n == 1:
        return False

    i = 2
    while i*i <= n:
        if n % i == 0:
            return False
        i += 1
    return True