Yegor Chernyshev

Yulian Kraynyak

## The Tech Stack

-   Typescript
-   React (Pretty much the entire app)
-   React Native (For easy porting to native mobile apps)
-   Redux (App-wide state management)
-   Firebase (Backend and NoSQL database)
-   Expo (Bridge the gap between the web and native apps)
-   Nx (Monorepository architechture to house all the code sharing)

---

## The Situation

During our undergraduate university years, me and Yulian created our own separate projects which differed in concept, execution and technologies. This particular project we started after a semester into our graduate studies at NYU and it was meant to be a culmination of our separate ideas, experiences and projects in our past into a modern and refined project that carried the best points of our existing works.

For me personally, this is a continuation of my [Rally](portfolio/rally) iOS project. However, this project was meant for a more global audience while also being more refined and narrower in scope. While Rally was primarily a project I used to learn iOS development, where I implemented tons of features and functionality no-one would ever use, this site was meant to have a more spearheaded plan that would allow us to solve a very specific niche.

![Breakroom's Pitch](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Frally_pitch.png?alt=media&token=755e65b3-6240-487e-b00f-85480be68dbd)

## Brainstorming

We wanted to allow users from all over the world to talk with one another about anything that interests them in the moment. We wanted to put likeminded individuals in the same mood together into the same rooms. The whole experience was meant to be engaging, interactive and dynamic. We wanted the application to feel alive, thus we also knew we had to get rid of those pesky zombie group chats where the conversation died out a long time ago. The primary purpose was to discover new people and perhaps make a friend or two. In order to succeed in this, we decided to make group chats temporary and live only as long as someone in it was contributing something meaningful to the conversation. Should there be no activity for several hours, the chat and all of its contents would disappear into the wind encouraging you to find other active discourse. Think of it more like an icebreaker, or maybe musical chairs.

## A Walkthrough of Breakroom

We knew from the beginning we wanted to hit three different markets: web, iOS and Android. And for each, we wanted the experience to be seamless from one platform to the next. We did not want users to visit our site and then have to download a separate app onto their devices. We wanted the site **to be** the app itself. This was tied in with our plan to allow users to create anonymous burner accounts. We preferred to have users who just jumped in for a while but contributed to the conversation over isolating people entirely behind a registration page. The entire application is one SPA (single-page application). Profiles, chatrooms, discover features, etc. all reside as panes on the home page. The layout is meant to feel more like a HUD where the center of attention is on the globe and it's activity, and around the user's peripherals are the details of the action. We felt it gave a more immersive feeling to the app that made it more alive than a standard chat application focused on dull scrolling text.

The entire application's backend is tied to Google Firebase. We use it to handle the storage of data, host the web app component, perform markeing, authentication and more. This allows us to focus more strongly on the front-end, where we can tailor the user experience and make for a more engaging experience.

We started out building the project with React Native exclusively, as our plan was to make the app mobile-first and then simply create a web landing page where users can learn more about it. I personally did not want to have this barrier to entry and as someone who hates being forced to download apps from app stores, I opted that we too make the web component an app in itself.

This lead to us briefly splitting our priorities as Yulian built up the mobile variant and I began work on the web aspect. Once we saw the potential of both and the many similarities of the two repositories, we set out to find a way to merge the two codespaces together and share as much of the code and components as possible. This led to us finding Nx, a monorepository package that allowed us to created different applications inside one repository with platform specific code inside those apps, while also creating shared components in separate libraries we could link to from any app. With the monorepo architechture we were able to share approximately 85% of the app logic and components.

I later optimized the performance of the application from a Lighthouse rating of **32%** to **96%**, decreasing time-to-interactive from **7.3 seconds** to **1.8 seconds**. An improvement of **75.3%**.

![Beta Signup Page](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fbeta-signup-breakroom.png?alt=media&token=fdc2e959-b9b9-4ab5-b276-47ae93ef7e12)

## Closing Thoughts

This project has been in the works for a little over a year due in large part to our graduate studies. It has been a deep dive for us into what it takes to build a modern web application. We also learned about collaboration on a production level scale, working as a team on one monorepository, posting issues, fixes and merges throughout our various branches. The journey is far from over, but the final piece of development is coming to a close. We intend to launch it Summer 2023. We will be happy if at the very least it touches some individuals across the globe and builds a small yet honest community. When I was a teen, an app like this was all I had wished for to exist out there in the world. And as an adult post-pandemic, I feel that it is even more necessary than before. To build connections and bridges between people and communities, not isolated echo chambers full of hatred for one another. But only time will tell if it becomes the vision we strive for.

**Launching Summer 2023**

[Signup for the Beta!](https://breakroom.chat)


Breakroom

# The Tech Stack

-   Swift
-   Objective-C (Very little, mostly for legacy package compatability)
-   CocoaTouch (including UIKit, MapKit and CryptoKit)
-   Firebase (Backend and NoSQL database)
-   Instruments (Testing)

---

# A Walkthrough of Rally

This app had many names: Rally, Lighthouse, Beacon, etc. And it had about twice as many iterations and redesigns. This was my first dive into serious software development and was a critical point in my journey as programmer.

## Backstory

**Feel free to skip**

So, another social media app. Haven't we had enough of those? That was actually one of my biggest and why I was ashamed to talk about it. This project was a continuation of an idea I had in high-school. Way back then, I coded up my first website in PHP. It started from an idea I had in a shower. I was having one of those lonely depressing days we all get as teens once in a while. It was a hot summer day and I was stuck indoors with a desire to go surfing and to learn how to ride a motorcycle (no really, this was my actual thought process). But I was only 17 and none of my friends had a motorcycle nor did any of them express the desire to go surfing. So I was too young to go out there and do it myself and too broke for any alternatives. Well, what would have been cool? To have something like a big brother to teach me both of those things. But that meant meeting people. Whhooo probably didn't live anywhere in my vicinity. Now I could have probably gone on Craigslist back then and written up some ad about the whole idea, but I liked my kidneys. The other alternative was Facebook, which I can't remember now if I deleted my account then before or after this idea came up. Nonetheless, it felt like towards the end of my highschool days was when Facebook was on the decline for my generation and people mostly moved onto hotter apps at the time like Snapchat and Instagram. Even still, I don't think Facebook 'Groups' was a thing at the time, so that wouldn't have been an option. Still, the problem with all of these platforms for me was their underlying algorithms: they were designed to connect you with people you know and let you slowly branch out to people you 'may' know. Well, what if you don't want nor care about people in these circles? What if you wanted to connect to people way outside? What if like me, you wanted to befriend someone who can teach you to surf and ride motorcycles far away? Well that was the idea behind that website I made at the time (called OneGroup...yikes, sounded like a cult) and then again when I got into college. So the year was 2015, and although the iOS App Store has been active for quite some time, it felt like there was a newfound buzz in the air for mobile applications. Just a year prior, Apple released their new language for iOS development called Swift. Why is this all about Apple? Well, I had two devices at my disposal at the start of college: an old Macbook Air and my trusty iPhone 5S. So naturally, I gravitated towards working with tech I already had access to and could test builds on natively. So I had a faint desire to learn what all the excitement was about and no better time to learn than with the introduction of a shiny new language that promised a lower-barrier to entry than learning Objective-C. Just so happened at the time that Apple had a built-in app on the iPhone called iTunes U (RIP, 2021) and me being a broke college student, I decided to look there first to learn Swift. And the highest course I found on that platform was Paul Hegarty's CS193 course from Stanford. (It is funny how sometimes events like this just line up by chance in our lives) The rest as they say...is history.

# Brainstorming

![Rally Flowchart](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Frally-wireframe.png?alt=media&token=3f632643-9c6c-4d7a-9e7a-ddc74e2f1fea)

When I set out to build this app, I knew nothing about iOS development. More specifically, I never had to build a program that interacted with the hardware on so many levels. This entire project was my learning curve and it lasted about 3 years, give or take, with various procrastination phases sprinkled throughout. Each time I learned something new, I tried to add it to the project. 


The app was originally laid out with XCode's Interface Builder and later when I learned about building dynamic layout changes with code, I switched to that. I tried to mimick the feel of the standard Apple App, as I felt this would result in the easiest onboarding for new users. A strong guiding stone on this journey was Apple's [Human Interface Guidelines](https://developer.apple.com/design/human-interface-guidelines/guidelines/overview/), a collection of principles for designing apps for Apple devices.

By extension, over the years I would strive to implement principles outside of design that Apple stressed, including security, accessibility and localization. I intended for this app to be used all over the world, so I approached the UI to be as flexible as possible when it came to implementing i18n localization. It was designed to be easily flipped for right-to-left languages and the UI was meant to dynamically expand and contract to play well with different languages and their encodings. This also paid off when implementing accessibility features as this allowed users with poor vision to be able to increase the size of the content without breaking the application.

## Closing Thoughts

Although when I set out to build this app I intended for it to become a published production-grade app, it instead wound up being a long learning experience and nothing more. There is always a possibility that one day I will return to it and remake it again with my new knowledge and experience and share it with the world. However, I feel my most recent project, [Breakroom](/portfolio/breakroom), is already becoming that. So this app and its code will forever remain in development hell as another project in my long list of C:/Desktop/random-project/random-project_5000_FINAL unreleased and unrealized creations.

And I hope it also explains my small list of existing projects. I never cared much to build calculator apps or some classroom based project to show off my skills. It has always been that a particular goal or vision in mind dictated how I went about my life. There is always an end goal 'build a small mobile app to let users all over the world connect over interests', and then I figure out the steps that I need to get there to make it happen.

And as **Ray Bradbury** said and **Reid Hoffman** later rephrased: _**"first you jump off the cliff and [then] you build your wings on the way down."**_


Rally

## The Tech Stack

-   Typescript
-   Next
-   React
-   Node
-   React Three Fiber
-   Tailwind CSS
-   MongoDB
-   Vercel

---

# A Walkthrough of yegor.codes

## The Brainstorming

The original goal of this site was to replace my existing static site with a more dynamic one while focusing on long-term service. I wanted it to be an extension of me and not just a digital résumé for recruiters. A sort of digital home where people from all of the world can visit to learn more about and connect with me. The core principle I had in mind was **modularity**. I wanted to have control over the full stack, from the client, to the backend, to the database and everything in between. The secondary objective was to make it as platform agnostic as possible. Not only in the sense of the client's machine, but also in the sense that I would be able to swap out the libraries, front-end components, backends, databases and more without changing the rest of the application. Kind of like one of those eco-friendly modular phone kits that keep trying to make it onto the market.

Throughout my entire programming career, I always started projects with a front-end focus. I like tinkering with designs and user-interfaces and building the exact experience I want my users to have. So most of the backend work I left as an afterthought (not really) that was glued together in any way possible to get the job done. My previous site was built with Google Firebase, a sort of Swiss army knife backend that handles much of the complexity for you, from providing database solutions to analytics, hosting, and more. So in order to achieve the goals I set out for this project, I had to decouple myself from such abstractions and learn to build and utilize databases and backends on my own. While on this train of thought, I figured this was the optimal time to learn what the big boys were using and perhaps learn new technologies that would give me an edge in the job market. Having already known React and having worked with NoSQL databases before, I decided to settle for MERN.

### Stack Decision

I decided I was going to learn the MERN (MongoDB, Express, React and Node) stack. The primary reasoning being it's popularity in large-scale production environments which meant learning the tech also made me a more competitive candidate for employment. However, I wanted to take it one step further and sprinkle in one of the hottest web frameworks out there: NextJS. I've been hearing about it more and more and despite initial hesitation to learn (seeing as I didn't require the Server-Side Rendering it was known for) I found it to be pretty inuitive to pick up. It also provided solutions to problems I didn't even know I had yet. One example is its handling of "slugs" for dynamic pages and another is its optimization for SEO. Aside from Next, this would be my first dive into Node and Express, particularly for writing APIs as well as the MongoDB database.

## The Walkthough

I originally wanted the site to have **four parts**. I wanted one landing page that supported a mini game environment in the browser full of models, animations, interactions and more. This was meant to allow visitors to learn more about me by interacting with a 3D representation of my room. The second part was meant to be a static "About Me" page that gave that same information but in a form that allowed visitors with slower internet and hardware, or those who relied on accessibility features, to use. The last two sections were meant to be the "Portfolio" and the "Blog" panes, which listed various projects I worked on and various writings I typed up, respectively. This project quickly grew in complexity as I started to add more functionality that would take what was originally a static site into a full blown custom CMS (content management system). A sort of investment for my future self. The main example of this was the admin dashboard I would wind up making for myself.

![Dashboard View](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fdashboard-pane.png?alt=media&token=90dda496-e460-4b93-92b5-04848b4f9b8e)

This dashboard was originally created to allow me to quickly type up posts on the fly without hardcoding it into the database or the build bundle. It quickly expanded to include analytics, allowing me to see the views each post got, the feedback I recieved and more. I then decided to connect the dashboard to my database and make the panes grow and shrink dynamically depending on the number and types of collections I had on my database. Thus, I expanded functionality to allow me  to perform CRUD operations on everything from my About page to the messages I received through the contact form.

![Edit View](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fedit-pane.png?alt=media&token=76b194d4-7ee7-4a40-a412-f20b304e5d95)

In order to allow me to sign into the admin section of the site, I needed some form of authentication. I previously relied on Firebase for that but decided to implement NextAuth this time around.

One of the last challenges I faced was in storing images for my site. I didn't have much content originally to share, so I depended on DropBox for custom uploads and then the original hoster like WIkiCommons for the images I borrowed from the internet. That all felt unsustainable as I don't like leeching off of other people's servers and DropBox isn't exactly an image hosting site. I was aware that MongoDB provided the GridFS API for such tasks, but dealing with the fragmentation of images and files into chunks felt like overkill. So, I decided to implement Firebase Storage to host all my blobs and image files.

Finally, this was all bundled up and deployed with Vercel. I originally planned to go for an Amazon EC2 instance and bundle everything together into a docker component. This was simply to learn more about Docker and the AWS ecosystem. But after doing the math for compute time, I figured it was a tad pricey and probably overkill for such a site in the meantime.


Yegor Codes

## The Tech Stack

-   Python
-   NumPy
-   Pandas
-   Google Colab
-   Jupyter Notebooks

---

# All Hail Big Brother

What better way to utilize machine learning algorithms than to use them to enact swift justice in the most privacy-violating way possible? Not really, I don't support a mass-surveillance state. However, in the last-minute crunching days of finals week we had to come up with a creative project that showcased most of what we learned during the course. Something that was relatively simple to get off the ground without requiring weeks of training models.

## Brainstorming

In the Piazza course section we were a part of, we heard it all. Students were planning to use ML models to predict food spoilage from photos, try to create language prediction models and more. We wanted to try our hand at something different, something applied and a little out of scope. After a few back and forth brainstorming sessions, we decided to try applying machine learning on surveillance footage. Typical surveillance footage is usually of low resolution to ensure it can be stored for a long time in a storage conscious way. Not every organization has the funds to allow 120 frames-per-second, 4K resolution video recording, 24/7, 365 days a year. So most solutions often revolve around using compression, lower resolution capture and even periodic captures every few minutes to decrease the size of the file. It all depends on the client's needs. We figured we could improve upon this shortcoming with ML. Our hypothesis was that we assumed we could take existing surveillance footage, upscale it to a higher resolution, perform object detection on those higher quality images and be able to detect more objects and with higher confidence scores than the original, low-quality footage. This was by no means an original idea (even our grading TA gave us a B+ for creativity), but at the time we didn't find any papers directly merging the two. Maybe we didn't look hard enough. Still, the project terms were not about originality, but execution. (We're certain governments across the world already implemented such systems, whether they want to admit it or not, at scales and with features we cannot even fathom.)

## Mental Walkthrough of the Process

There are many ways to validate the efficacy of a machine learning model: the number of correctly labeled pieces of data, the quality of a supersampled picture, correctly predicting letters in a hand-written note, etc. We needed some quantitative value to merit the success of our model. We decided to use the object detection aspect as both a secondary challenge for us and a metric for evaluating our hypothesis; the scores we needed that told us whether we succeeded or failed in our goal. 


Our approach originally had promise, and by the time we got up to the point of upscaling footage and running detection models over it, we were too close to the deadline to back out. Below is output from our Colab notebook applying our process on a real surveillance image.

![Our Approach's Promise](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fpromise.png?alt=media&token=32681aaf-9e5c-400d-9cae-995c1dd4b7f6)
*Object detection scores over the original surveillance footage (left) Object detection scores over the ESRGAN Enhanced footage (right) Due to the resolution enhancement of ESRGAN, the output text and bounding boxes created in the python program are scaled proportionally, leading to difficulty reading. Thus, for added readability, I duplicated the output detection scores here.*

We saw instantly that confidence ratings in the upscaled images rose across the board. In this cherry-picked image alone, we saw ratings going up. This was one of our first tests, so we were stoked.

## It All Goes Wrong

So, you might be thinking to yourself, higher resolution photos coupled with object detection means higher rates of detection, common sense, right? Not quite, at least that's not what came out of our project. In some instances, object detection went up by near 30%, in other instances, such as when applying our workflow to surveillance videos, our detection plummeted. 

![VisDrone Dataset Results](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fvisdrone-results.png?alt=media&token=e0d8d6c0-10ea-4b9c-a20e-927a2c14bfcf)

Taking over 1400 images from the VisDrone dataset, we reached a marginal increase in detection confidence scores, from 56.6% to 56.9%, hardly something to pop bottles over.

![Input Video](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Finput-video.gif?alt=media&token=b40cb041-3245-4f5c-a083-3e1834913538)

![Output Video](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Foutput-video.gif?alt=media&token=1a689b35-bebd-44fd-894c-148e04d0b27d)

![Video Results](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fvideo-results.png?alt=media&token=6cbccf87-708b-429f-adf8-f73a3932e0e6)

When it came to running this model over a 240p dashcam video, the results completely bombed, dropping from an average confidence of 38.5% to 30.5%, painful to say the least.

## All Hope is Not Lost

We have a few theories as to why that might have been. The first elephant in the room was that the object detection model we were using was re-trained on a very limited dataset, not enough to properly tweak all the parameters for solid detection. (We did briefly attempt to retrain the detection model on our upscaled images to improve scores, however even with Google Colab's GPU support, we needed over 11 days to train it. Something we did not have at the time.)

![ETA of Model Retraining](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Frunning-out-of-time.JPG?alt=media&token=c3d45662-d73f-48fa-86ee-2695cd6b4fa9)

The second issue was something we noticed only after getting well into the project. ESRGAN, while doing a fantastic job of trying to increase the resolution of low quality images, also resulted in some expected artifacts in the images. 

![Artifacts from ESRGAN](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fartifacts.png?alt=media&token=073c111e-af84-4be2-8c8c-95acbb789733)
*Originall surveillance footage (left) ESRGAN enhananced image (right) Noticable artifacts are appear in the enhanced image, particularly around the tires of the gray car and around various details of the white cars.*

![Artifact Close-up](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fartifact-close.JPG?alt=media&token=9e50cb97-497d-46bf-ad15-b7e5bdb21b39)
*Close-up of the ESRGAN enhanced image*

These artifacts, while not mission critical to the human eye, are significant enough to most likely confuse object detection models trained on normal images. This could all be fixed most certainly given enough time and training of object detection models on super-resolutioned images. 

In closing, this was meant to be a fun, end-of-semester, project allowing us to flex our muscles on all that we have learned throughout the course. We did go a bit above and beyond in our scope, but we learned a lot about how real-world model training and evaluation is done. Sure, the raw results aren't great, but we were happy enough to know the damn idea worked and that we actually were able to pull this off. We are certain that given enough training data, computing time, resources and caffeine, this could actually be implemented in the real world with much higher rates of success than we achieved here. However, we leave that to other teams and curious students to tackle and leave this work squarely as just another project for a university course.

NYU Machine Learning Project

*No, this bot was not made to scalp, I take pride in my morals.*

## The Tech Stack

-   Node
-   Puppeteer
-   Discord API

The name Marvin refers to the paranoid android from Hitchhiker's Guide to the Galaxy and the Useless Bot part is a nod to the butter bot from Rick and Morty. There isn't much to say about it, but I figured I'd add it anyway because it was fun to implement. 

# Enter the Pandemic

Supply chains were bust, people were bored and prices were at an all time high. If the first line didn't make it clear enough, scalping was also a very common practice. People would find ways to buy up products high in demand and low in supply and try to resell them in the aftermarket for extortionate prices. You had about as much luck trying to get anything you wanted at retail price as winning the lottery.

Marvin the Useless Bot was my personal solution for my own needs during the pandemic. As his name implies, he was useless. His only purpose was to track certain websites and send a push message to my Discord account if any notification state was changed about a product's availability. He did **nothing else**.

So if he was nothing more than a glorified push notification system, why is he worthy of a spot on the portfolio page? If my other projects don't showcase it enough, I have a tendency to take small ideas I have and blow them out of proportion. My personal world of feature creep. 

![Marvin Gains Sentience](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fmarvin-sentience.png?alt=media&token=0786c37f-57e9-43f3-bbce-39574ec7e502)

In creating Marvin I gained solid exposure to Node and RESTful APIs. It was my first dive into working with JavaScript entirely on the backend. On top of that, I went down the rabbit hole that is web-scraping. I had previous professional experience building web-scraping scripts in Python for my job in the financial industries. If you're unfamiliar with web-scraping or "spidering", the idea is to collect information on the internet that exists on sites that may not provide a conveient means to access it. (Yes, this may be abused for nefarious reasons, but here we are strictly approaching this from an ethical standpoint.) Usually this means a site may not have an API setup for the data. If you are dealing with small or infrequent data, merely going onto that site and manually copying it might suffice. However, in the case of my job, I was dealing with daily economic data that was sometimes provided by the source on an almost hourly basis. For most of the data we acquired, we had partners, contracts and API keys to acquire the latest and greatest in the financial markets. However, when it comes to economic data in developing nations, particularly monetary data released by central banks, the data is often uploaded on static sites with little to no means to efficiently acquire it on a frequent basis. Enter our friendly neighborhood spider-bot. Assuming you have consent from the data provider to scrape their data, you can build automatic scripts that can go onto these sites and extract the data directly from the HTML it sits in. If you know what you're doing, you can easily acquire data from a provider the second it is released and leave a digital footprint as large as any other user visiting the site (or even less)! This is actually fantastic news for everyone involved, as this leads to less bandwidth and strain on the provider's servers and for your own client device! That was a long winded example about how web-scraping can be used in production and ethically. But for me, having a web-scraping library in JavaScript opened a world of possibilities. JavaScript is, after all, the language of the modern web. So having a single language to be able to fetch and wrangle the data felt like a massive boost in efficiency for me.

# How He Operated

All the target links that I had Marvin track were static direct URLs that I checked out personally beforehand. This was done for many reasons. For one, Marvin didn't have much freedom, so recursively tunnelling to find what I was looking for was off the books. Second, although I had plans to expand his functionality, I pretty much held his hand in finding the elements on the page that I was interested in. When the data was fetched, it was stored in an SQLi instance where I could keep track of the target, the timestamp of each request, the response and the state of the element I was tracking. The gameplan for the database setup was for tracking long-term price changes. That way, deviations in retail prices months later could also be noted.

## All Hail Efficiency and Morality

Marvin may have been useless, but he was a good boy. I developed him to be as noninvasive as possible. At his highest page request rate, he was limited to a single call to the target every five minutes. At his slowest, I limited him to one call every 24 hours. I even had plans to implement in a dynamic rate system, one that would increase the calls as changes to the site became more frequent and slowed down the calls if no data update was found between subsequent requests. Furthermore, I kept Marvin's link-depth to 2. He was only allowed to examine the target page and any links that pointed from it by one link click. I didn't have any reason to increase this number and my paranoia kept me from trying that even if I wanted to. With the number of links on a modern web page such as an e-commerce site, you can quickly get into hot-water with a roque bot.

![Visit all the Links Meme](https://firebasestorage.googleapis.com/v0/b/yegor-codes.appspot.com/o/uploads%2Fvisit-all-the-links.png?alt=media&token=82b16173-f657-4df0-8a2c-eb218ccbc532)
*It's 10PM, do you know where your bot is?*

## Gone too Soon

Marvin reached his EOL at the end of the pandemic. Rest in peace lil' buddy.*

*Unless I find another use for Marvin. We had a lot of memories together, but he needs more usage, I figured about extending his capabilities outside of Discord and opening him up to the public but not quite sure what I could do with him that isn't already readily available with other bots.

Portfol.io

precious trinkets I made

Web

iOS

Android

Breakroom

iOS

Rally

Web

Yegor Codes

Machine Learning

NYU Machine Learning Project

Bot

Marvin the Useless Bot