Code With Rex

Hobbyist’s toy or serious endeavor?

Computer Science is a very broad subject and it often feels like the more you know the deeper the well of untapped information becomes. I grew up in the 90s and my father was a software engineer for my entire life. Back then computers were far less common, the internet ran mostly on dial up, and no one had a mobile phone. I started messing around with code at about age 5 in a simple language called Q BASIC on our old 386 machine. Through the years I moved up to HTML, CSS, Javascript, Perl, C, Python and many more. Throughout my time at OSU I’ve had to take on some of the most complex logic problems I’ve ever encountered in classes like Analysis of Algorithms and Operating Systems. Creating a command line interface in C is something I never want to have to do again. I’m glad for the experience I’ve gained, the complex sorting algorithms and games I’ve had the chance to program here. But before I got back into school for a second degree in Computer Science, before I could write even a bubble sort on my own, the thing that really got me interested in programming in the first place was web development.

To me web development is like a rube goldberg machine; one big elaborate setup of precariously placed parts that maybe, just maybe if everything goes according to plan is a fascinating chain of events that most people take for granted. A lot of programmers take web development for granted. I’ve seen it looked down upon as being simplistic, not ‘real’ programming, not requiring a degree and mostly relegated to bootcampers who skip the longer term commitment of getting a formal degree in computer science. A friend even suggested to me to go to a bootcamp instead of school if all I wanted to do was web development. I did, and I tried to freelance on my own and it didn’t work. Luckily I stuck with it and I’ll be graduating with my Bachelor’s of Science at the end of this term.

 In some ways it’s understandable why this pejorative opinion of web development pervades. In its infancy the internet was a military tool for long distance messaging. In the 90s when I was a kid, ugly and slow loading html pages were the norm. Google wasn’t around yet and sites like Yahoo, Northern Light, Alta Vista, and Lycos were constantly fighting for search engine users (Yes I used all of those). I remember in middle school being part of the “Advanced Computer Programming” class where one of our main class projects was to update our school website. What really captivated me about web development from the start was the fact that html was so immediately gratifying. You could edit your code, reload it and immediately see visual results of what you had done. I remember spending a weekend figuring out how to make the school’s Spanish language page play a midi file of latin music in the background when the page loaded. Thankfully I’ve moved away from such tacky designs these days but that creative aspect is what really made programming fun for me in the first place.

I can safely say that I’m not the only one with a love for the web. CSS Zen Garden is an online shrine solely dedicated to the pursuit of beauty through css stylings. Video games are created and entirely enjoyed in the browser (check this recent google doodle). I myself have created interactive web applications just for fun:

One thing I can say for sure though is that the area of web development is not just simple and easy. HTML and CSS can on the surface make it all seem that way, but having worked professionally and academically on multiple projects involving: Angular, Microsoft Azure, CosmosDB, MYSQL, pHp, HTML, CSS, Javascript, React, Vue, Gcloud…. (the list goes on) there are always so many moving parts to keep track of. It seems like new libraries come out every week and a cursory look at jobs in the field back up the sheer variety of skills needed to work in this industry.

The important point about all of this for me is that Computer Science is a huge space, with tons of different areas to work in all of them are important. Sure new technologies such as AI or Machine Learning come along and drum up all the popularity and attention with them. But the web is still a hugely important part of the world. It lets you buy furniture on Amazon, video call your co-workers, play movies on youtube or do your banking from your phone. And even though throwing up a blog can be as easy as making a squarespace account, there is a huge amount of variety of applications and some of them are vastly complicated as well. Check out this awesome project from folding@home. I think it’s fitting that my final project is a web application as it brings me full circle back to my starting place in seventh grade. I look forward to finishing this project and starting the next one for many years to come.

In the journey from coding personal projects and tutorials to full fledged professional applications, one of the biggest hurdles to overcome in my opinion is moving away from tiny datasets, “mock” databases or simple text files and instead interacting with real, actual databases. Not to say there aren’t skills and experience to be gained from smaller and more beginner projects, but there is a reason most of the websites and applications produced by major companies almost always involve a database. Databases allow data to be personalized and to persist, and allow all kinds of modern day tasks we take for granted are organized, queried and edited thanks to databases. And in the world of databases the biggest question from the get go is usually: SQL vs NOSQL (or relational vs non-relational/not only relational)?

With the introduction of computers into the business world in the later half of the 20th century, databases became a necessity for organizing and managing data. The first and largest solution to come about was the SQL database. According to https://www.ibm.com/cloud/blog/sql-vs-nosql:

“SQL, which stands for “Structured Query Language,” is the programming language that’s been widely used in managing data in relational database management systems (RDBMS) since the 1970s. In the early years, when storage was expensive, SQL databases focused on reducing data duplication.”

However in more recent years there has been the development of so-called NOSQL or Not Only Structured Query Language databases. SQL was necessarily developed in a very rigid format, putting data neatly into tables and requiring each piece of data in a table to adhere to the same rules. But inevitably there arose cases where people wanted to break out of that system, and create more dynamic databases where rules are looser and the formats can take on many different forms. NOSQL in comparison to SQL allows for a variety of Database types, such as Document, Graph, Key-Value Pair, and Column (as shown on https://builtin.com/data-science/sql-vs-nosql)

So what’s the point of all this? Well in both my full time job and my current capstone project at Oregon State University, one of the first design choices that needed to be made was an SQL vs NOSQL database. So how does one go about making that choice? One of the traps that is easy to fall into when going through school is that you often get very busy completing assignments on deadlines, and following instructions and rubrics to satisfy the requirements of what you’re meant to do. But in my experience, in the workplace you don’t always have the luxury of someone telling you what to do or how to do it. Being able to design and execute well thought out plans on your own is a difficult skill and one of the most valuable things you can do in the eyes of many managers. So as I work with my team creating our project this term, it seems like a good idea to catalog the important decisions that are being made and how we made them.

Let’s start by taking a look at what we have to work with. The project I’m working on is a job tracker web application that let’s users keep track of and to some degree analyze the job applications, contacts, and skills they upload to the website. Seems straightforward at first glance, but adding in the ability to let each user keep track of their proficiency in each skill, sorting which skills appear most across all of their applications, and adding contacts to multiple applications quickly complicates how each piece of data must interact with each other. So, which type of database should we use?

It’s important to think about the fact that our group has varying technical experiences and that we have to complete our project in the span of a ten week class. We all took mostly the same classes at OSU and this as well as time constraints played a big role in our final decisions. But to break things down, one of the things I did was take a look at some of the information on https://www.talend.com/resources/sql-vs-nosql/#:~:text=SQL%20is%20the%20programming%20language,generally%20do%20not%20use%20SQL:

“To make informed decisions about which to use, practitioners should be aware of the differences between SQL, NoSQL, individual Database Management Systems (DBMS) and languages, as well as the situations each is best-suited for, and how the landscape is changing.”

It goes on to suggest the five main differences between SQL and NOSQL databases are Language, Scalability, Structure, Properties, and Support/Communities. Let’s take a look at each in the context of our project.

Language

The first in the list is language. SQL has several different distributions, but while there are a few syntax differences they all more or less provide the same core operations and ways of doing things. My group members all had experience in the database class with MySQL and certainly that would be an option for us.

However NOSQL has much more variety in types of language. From JSON style documents to graphs to key-value pairs, there are a lot more options here. All three of our group members took the Cloud Application Development class at OSU and all had used Datastore as a NOSQL database in that class, which again lent itself as a viable option. No major determination yet.

Scalability

Moving on to scalability, many online resources state SQL databases can be scaled vertically (meaning increasing RAM or CPU power), while NOSQL typically are more easily able to scale horizontally (through sharding or running the data on multiple servers). We already planned to deploy our application through GCloud which meant that both were in some way possible, but really comes down to pricing. Cloud in particular is by nature shared across servers so horizontal scaling would be an easy option with GCloud.

Structure

The third difference on the list is structure. As previously stated, SQL is all rigidly and necessarily defined as Table based data, and requires a good deal of planning and creating of schemas before developing. In a way the stakes are high because a badly designed database in SQL is more or less locked in and the only real way to fix it is to start over. Not ideal for a short timeline. On the other hand NOSQL is flexible by nature, and can be adapted or changed in some ways as development happens. New data can be added without following old rules necessarily. It does also run the risk of poorly defined designs, but in some ways allows for quicker response and mitigation of these issues. This is a point for NOSQL.

Properties

Fourth in the listed differences of the article is Properties, and this basically comes down to the principles adhered to by each database type. SQL again tends towards rigidly defined rules such as Atomicity of data (each transaction must fully succeed or fail) and Consistency, while NOSQL is again more loose. For a smaller database built on a short timeline between three relatively inexperienced developers, it again feels more flexible and lenient to choose the NOSQL option.

Support/Community

Finally the last practical difference in the article is Support/Community. SQL has been around longer, is better documented and essentially has more of this. This sort of gives a point in favor of SQL but with a caveat; All three of the developers on my team had worked in the Cloud Application Development class using Datastore (NOSQL), and we all have coding references from that class, while none of us have used an SQL database in GCloud. In this way we probably have more familiarity and more help resources at our fingertips with the NOSQL option. It’s always important to take into consideration what you are personally more skilled in and if it’s worth learning something new for the sake of a project.

In the end my group felt the flexibility and familiarity of NOSQL with our technology stack was the better choice for our project. However we have already had a few instances of having to redesign our database due to the fact that the increased flexibility means increased room for error.

I think this portion of the project has shown me how much of what developers tend to focus on is pure code, and how many other elements like design and understanding project requirements are important and sometimes not focused on enough. Hopefully our solution will be successful and serve to better inform our projects in the future.

As I enter what will be my last term finishing up my second undergraduate degree at OSU, the first thought in my head is “how am I going to get through this?” We have to pick a project, make groups, and deliver a finished project in just 10 weeks. And then it occurs to me that 2023 marks 12 years since the first time I stood on the very edge of receiving a college diploma.

And things couldn’t be more different.

I was born and grew up in Corvallis Oregon, back before Portlandia was a show, before we had a Winco or Home Depot, and before I had any idea what I wanted to be when I grew up.

My first stint through college was a path of least resistance. I remember in high school a motivational speaker coming to our school and proclaiming at an assembly in front of the entire student body “There are those people who are lucky in this world to be blessed with the abilities of a pro athlete or a prodigy musician. For all of the rest of us, there’s college”. I have never to this day heard a less motivational speech in my life.

I’m the youngest of four kids. I was born relatively poor, and my father was hospitalized for a major knee injury the year I was born. However that was also the year he went from moving furniture to software engineering as a profession, and a lot of things dramatically improved because of it. At 5 years old in 1993, I was sitting at a very expensive and rather primitive desktop computer making tiny little programs on QBASIC in Windows 3.2. I had all kinds of reasons to grow up to be a software engineer. But by the time college came around, having already been through a few programming classes, I wanted to see what else there was, if I could do something different than my dad and brother did, and if I could make a different life from the obvious one in front of me. And for the next decade or so I did.

In my first foray through college, I spent the first two years with an undeclared major. I went to parties, I dabbled in a bunch of different classes, and I worked part time at the alumni center. A trip to Japan with my brother and his wife pushed me to start taking Japanese as a minor, and I ultimately went to Japan for a study abroad program in my last year at OSU. I cannot describe what its like to have lived in Corvallis, Oregon your whole life for 22 years, and to suddenly move to Tokyo, Japan, the largest populated city in the world. The food, the people, the language the culture, all of it just opened the world up for me. Unfortunately, that happened to be the year of the massive Sendai earthquake that ravaged the country and lead to a hasty evacuation for myself back to the US.

I landed back in Portland waiting on the term to end as I suddenly had no school, no diploma (yet), and no job or prospects. A friend I met in Japan and I went to a bar and over a few beers I was convinced to take his advice and travel and work in a few national parks across the US. After a brief period of joblessness I managed to spend a few incredible seasons working at Glacier National Park in Montana and the Grand Tetons in Wyoming. Traveling was wonderful but tiring and after my second park job I tried to settle down into a real job for a while. I found temp work in a warehouse through family and eventually went to work as an employee assembling printers for a small tech company. Time moved on and I started to stagnate. I wasn’t really making very much money and I wasn’t seeing much future simply assembling things on the line in a warehouse. When a merger came through the company I jumped from assembly to research and development and started looking back at programming again on the side. It had been many years since I had touched it and I had to start over again. A friend sent me a link to a 90% sale on a web development course online, and $10 later I was back to making javascript games in the browser. Back at work, I started to notice a lot of repetitive and time consuming tasks that I new I could automate with programming. At first it was a way to keep myself from getting bored and to learn some basic Python scripting along with web development. But when I was given a folder full of files to update that normally took days worth of time for data entry workers to do and I ran a script to do it in less than 5 seconds, my manager took notice. One conversation later and I was approved to go back to school and begin working towards a career in software development.

So what has changed from my early 20s to my early 30s? Well, a lot. The first time I went through college, I went because I didn’t know what else to do. I was trying to see what the world had to offer, what was possible. In my 20s I wasn’t worried about buying a house or paying a mortgage, I was worried about how to travel to places I couldn’t afford to go. The second time through college I had a plan. I wasn’t there to go to parties, to meet new people, to go to football games, or to explore the world. I went this time to get a career. And as of March of 2022, I started my new role at my company as a software developer, so in that sense I’ve already accomplished my goal. But for all the difficulties and spent time it took me to get here, I feel like its given me a unique perspective I would not have had if I simply stayed in Corvallis and took the obvious road from the get go. If there is anything I could offer as a life lesson or advice I’ve gained from all this, its that you never know what’s out there or what’s possible until you try. Sometimes figuring out what you want to do is really about marking things off the list. There are endless possibilities both in life and in programming. The only way to get to a solution that works is to try take the first step, and to see where it leads.