One of the things that makes computer science such an appealing major for a lot of people is that the software industry is a skill-based industry. It really doesn't cost much to get started writing code. All you need is a working computer, an average IQ, and a good amount of grit and persistance.

I made a discovery today. I found a computer. Wait a second, this is cool. It does what I want it to. If it makes a mistake, it's because I screwed it up.
- The Conscience of a Hacker

But what happens when you can't even afford the hardware to run your code? This was my problem. Back in 2018 I was renting a house with three other guys back in Baltimore county. I was working as a dishwasher at the local Pizza Hut (i.e. I was a soap engineer). Striking out a living for yourself when you're making minimum wage is a bit rough, but I made due. Having three roommates kept the rent down.

So plowing right ahead, I had just signed up at the Community College of Baltimore County pursuing a major in computer science. Honestly my choice of major was about as arbitrary as it wasn't. When I was a kid, all I had growing up was a hand-me-down OG big black dummy thicc Xbox that my uncle had given me with three games. I wanted more games. So I figured, given buying more games was not on the table, that I would figure out how to build my own so I'd have something else to play.

I did not produce any good games. I may have nuked my computer a few times.

Anyway, that's basically how my interest in software development began.

We Packing Chrome, Baby!

I did have a problem though. In 2018, given I was a soap engineer, I didn't have money for a decent computer. Before my first semester started, I walked to Wal-Mart and bought Google Chromebook for $180, and even that was putting my in a financial pinch. Unfortunately Chromebooks can't really do a lot. A Chromebook is built just to access the internet. When trying to do anything else with it, it's a brick.

In my first intro to programming course, where of course we were using good old Java, I could not for the life of me get my Chromebook to natively run Java. This was just before Chromebooks had added support for running a Linux command line so my Chromebook was super limited in what I could do with it.

So what I discovered I could do though was to use the AWS Cloud 9 IDE, write my Java code there, and export the files, and submit that to my teacher. Boom! Problem solved. Seems the brilliant problem-solving skills I had learned as a soap engineer were finally paying off.

The only issue I ran into with this approach was some time zone shenanigans. We had some assignment that involved formatting the current datetime as a string, and the Java code, when run on the Cloud 9 IDE, would display out the time zone of the server the code was running on, as I understood it anyway.

This was a while ago, so bear with me, but I solved the problem by setting the locale via Locale.setDefault(new Locale("en", "US")). It's been a minute since I've worked with Java but the solution was something to this effect. I figured I would note this here in case any college students are reading or trying this and run into this problem.

Yummy Yummy Croutons :)

Fantastic! So we have a solution. But I needed... a better solution. This got me through two classes in community college, but having to develop and test all my code in the cloud was a bit rough. The irony of that statement is that I later became a Salesforce developer.

I also felt I needed a better solution as I was transferring to the University of Maryland, a top 10 CS school, where I felt like this hacky solution wouldn't quite cut it. So I found a hackier solution!

Fortunately there are brilliant engineers in this world who have solved this same problem and shared their solutions on the internet. Because of the fact that at its core a Chromebook runs on a Linux kernel you can hack a Chromebook so it can effectively dual-boot Ubuntu. As I understand it, there are other ways to do this now, however what I used back in the day was crouton.

Crouton is an acronym for "Chromium OS Universal Chroot Environment". A chroot works like a virtual machine. The Ubuntu file system is segregated and applications are allowed to run in a different binary environment than that of the root operating system. There are some questions about how secure this is, but anyway...

The trick was to run the Chromebook in developer mode, open up the Chromebook's shell, run the crouton installer via the shell, then you can jump back and forth between the Chromebook's OS and Ubuntu with key-bindings.

This worked, and it's how I got through my first two semesters at UMD. However, running eclipse in the chroot would occasionally cause the screen to flash and freak out. This was tolerable given my constraints. All things considered I don't imagine eclipse was built to run like this. It got the job done though.

Cool! So using crouton got me through most of my classes however my junior year I took a data science course. For those who have never done anything with data science, essentially when going through the database to examine the data, the entire fucking database is loaded into RAM. I had a Chromebook. My poor baby could not handle that.

This required yet another hacky solution.

R U With Me?

So the course was taught in the R programming language, an evil language that indexes from 1 instead of 0. R also has its own massive suite of tools, RStudio, comparable to Visual Studio, and it is an absolute beefy boy of an IDE.

I had a buddy of mine who had mentioned Digital Ocean a few times as a service he'd used to spring up remote servers, so I figured "hey, I wonder if I can use a remote server to do my development to get around the constraints of using a Chromebook". Turns out you can!

On Digital Ocean you can create "Droplets". To create a droplet is to provision a server that you can connect to via SSH and also HTTP. I found someone had already created an image for an RStudio droplet, so for my data science class, I would spin off an RStudio droplet, which would open up a web portal to access the RStudio IDE, that I could log into and develop my code. I would then push my code to GitHub to persist it and destroy the droplet to save money on resource usage.

Boom! With that approach, I got an A in that class.

I will note that I didn't really understand security at this time. When I first started provisioning servers I was just using basic password authentication. In other words, my servers kept getting hacked by crypto-mining bots. That was wild. So yeah, pro tip, use an SSH key when provisioning your server so that doesn't happen.

As and Bs are Cool, But Money is Cooler

There was one final problem I needed to solve. I could get as many As and Bs as I wanted in college, but the point of going to college, at least for me, was to land a job. I'm not saying the grand pursuit of knowledge has no value, college is a fantastic resource for that, but I'm just saying, I did not want to graduate college just to go back to being a soap engineer.

So what I understood was I needed some sort of portfolio site or some sort of public site I could use to demo to employers to demonstrate that I actually learned something in school. The goal here to was snag an internship my senior year so I could hit the ground running upon graduation.

At the time I was a huge fan of doing hacking challenges on hackthissite.org so I settled on building my own version of this in React, with Redux for global state management, with an Express back-end, with my own hacking challenges, and a web forum whose posts were stored on MongoDB. I called it hackthisMEANsite (technically it's the MERN stack, but that doesn't sound as cool).

At some point I might revive that project. I do think it was interesting, but that's an aside.

So building on a Chromebook just didn't sound very fun, and since at this point I'm comfortable saying I had leveled from from a soap engineer to a software engineer, I figured some over-engineering was in order.

Subliminal Messaging

I discovered something called Remote Sublime. This was forked from another project called rsub, which at the time I was learning all this, was dead. Remote Sublime allows you to connect to remote servers via SSH and edit the files of that remote server using the Sublime text editor.

In hindsight, there might be something to be said about the security implications of building out a site designed to be hacked on publicly accessibly servers, but anyway...

It was a bit tricky to piece together how to do this, so I'm going to note it here.

• In Sublime, on your local machine, install the Remote Sublime package.
• On Digital Ocean provision an Ubuntu droplet.
• On the remote server, run the install script listed on the Remote Sublime GitHub repo.
• Connect to the remote server from your local machine via SSH.
  • ssh -R 52698:localhost:52698 user@example.com
  • The -R flag is for port-forwarding, Remote Sublime defaults to using port 52698.
  • user@example.com, translates to the user and the domain.
    • With the Digital Ocean droplet, what you would probably use is
      • root@{{Droplet IP Address}}
• From the server, rsubl is the command to open and edit remote files locally in sublime, for example rsubl test.txt
  • Sublime must be open on your local machine for this to work.

And that's it! My workflow was to spin up a droplet, install the connect script, connect from my local machine, clone my git repo onto the remote server, then I'd work on it with sublime. A hacky solution, but as they say, it ain't stupid if it works.

I got the site up and running and built out about a dozen separate challenges varying from MongoDB injections, prototype injections, XSS, and insecure authentication. I did build the web forum as well. The UI was a little rough, but it worked.

I later took this site to a job fair hosted by my school and demo'd it to potential employers. With this I was able to score my first industry job as a React developer at a local startup. In my old bosses words,

You were the only person who applied who demonstrated you could build an app from start to finish

Closing Thoughts

It's funny; I never thought of this as something noteworthy until I mentioned this to a buddy of mine the other day when we were getting food downtown. He was shook by the idea that I was provisioning servers all the way back in college. He did get a kick out of the part about the crypto-bots though.

I never thought about it that deep. It's a wild story, sure, but I figured it wasn't that wild because given the same constraints, I'm confident someone else who was sufficiently motivated could have come up with a similar set of solutions.

It reminds me of a lot of the junior engineers I've worked with who are short on confidence, stuck with imposter syndrome, thinking they can't solve the problems they're presented. You know who really feels like an imposter? The guy building all his apps on a hacked Chromebook because he can't afford some decent hardware. Don't sell yourself short. You're probably doing fine.

I suppose my parting words on this story are ~

You're here.
You didn't get here by accident.
You can figure this out.
I promise.