Summary:

I wouldn't call today productive. I spent a lot of time writing code myself, diving into the world of concurrency, but nothing major. I did not generate anything significant on my own. And that is what is usually required at a workplace. I should focus more on that tomorrow. Switch from a "reading day" to "applying the knowledge day". Also I identified a couple of typos in the rust by practice repo, and I should edit them. At least in this way I can be useful to people. Also, throughout the whole day today I kept repeating the words of YouTuber GothamChess about actually finishing the courses. Just saying you learn something is not enough, you need to complete books/courses from start to finish. Yes, maybe the brute-force approach is not beautiful and elegant but it will yield a result. I sound like one of those motivation-centered online gurus right now :)

Rust by Practice

Mara Bos Book:

  • I decided to make a new repo where I can execute each of the examples as: cargo run --example ch<num-chapter>-ex<num-example>-<num-example>. Because just sharing gists for the commented code, like I did yesterday is strange. I moved all the examples from Chapters 1 and Chapters 2 there. Here is the commit
  • Finished Reading Chapter 2.
    • Work
    • I am comfortable with Atomics.
    • I can spawn threads in many different ways and use closures correctly.
    • I understand the idea behind compare_exchange method.
  • Started Reading Chapter 3.
    • Work
    • Happens-Before Relationship can be achieved between the threads.
    • Compiler still has room for optimizations with Rust's memory model.
    • Wrote my first bit of unsafe rust.
    • Mutexes just use the Release-Aquire ordering to establish happens-before relationships.

EliteCode

  • This is the project I found yesterday on /rust subreddit. I like the concept. Each of the problems: virtual file system, URL router, TTL cache can be its own project in separate repository. But setting everything up is so time consuming. I would rather use an online platform with tests. Nobody will use a rate limiter that I wrote, and I want (some day) for my GitHub to be a place where people go for code they can use. (Doesn't connect well with a new repo I created in a section above though :| )
  • Today I worked on the Sliding Window Rate Limiter. The problem was marked as easy, so it was the obvious one to start with. My approach was simple, we have a number and we need to check in how many intervals it is already present. Intervals are sorted, and can be defined by one number, as windowMs is constant. If number of ocurences is above the specified threshold, return false, otherwise add an interval corresponding to the input number to the Data Structure. BTreeMap in Rust seemed like a right choice, as we want to be able to get a range of entries on-demand.
  • You can see my implementation here.

Dutar

  • Fix the bad logic I wrote for deleting the currently playing song from fs, so that it is removed from the queue.