Remix Rules :)

In my limited time of front-end development – which is not a lot considering that I am mostly a back-end developer – I’ve had a love hate relationship with React.  Overall React can be confusing, but it is a very powerful front-end framework that allows for the componentization of things so that they can be reused.  This is great because software engineers don’t want to type more than they must.  This also allows for single page websites to be created pretty quickly and allow for state to be handled on the fly.  If you want to make a website that calls a lot of back-end sources, it is nice.

The problem is that there is a strong emphasis on single page websites, which is not always what a developer wants to create.  Routing of different pages is possible, but its long complicated, and you must deal with the previously mentioned state change functions from firing in every single page.  For example, if you have a blogging website that uses a state function to get all the blogs for a page, it might end up trying to check the blogs on every page, even if you don’t want that.  This can be fixed, but you can see how this can become a tangled web fast.

For example, below is a React route switch for different pages.  This would serve up the Home component on route / and the Second component on route /Second

Example of routing in React without having to deal with state.

Now you could imagine that since this gets pretty annoying fast, there are libraries and tools out there to speed up this process, and make it less confusing.  Which is where Remix comes in.  Remix is a framework built off React that handles a lot of this routing for us.  Below is an example of how Remix handles routing, routes are done at the folder level, so to get the main Jobs page in this example the route would be /Jobs, where the index component is automatically served up.  Any other components for the Jobs page are then pulled from the components folder. 

Example of routing in Remix with components

This is more in line with normal website development methods where the pages are served up page by page, but combines it with everything good React has to offer. This means that we have the benefit of using React states without having to keep our site as a single page site. Because of this, we decided to use Remix for our Job Tracker application.



Something about website development that has always mystified me has been the cookies.  Overall, as a concept, I’ve understood what they do, and how they work, but when it comes to practice, I am at a loss.  So, when it came to the Job Tracker application, I learned that I would have to deal with user login, I got very scared.

For those who don’t know, I’ll explain the general concept.  When a user logs in to a website, their information is authenticated on the server against the password they have stored previously, and if that is successful, then the server will generate a cookie that stores basic information on the user like their user id or username, and that is sent back to the user.  This cookie is then stored on their system, and every time they access the website again, if the cookie is still valid, then they are given access to pages that are specific to them or show them the logged in version of the website.  When a user clicks on any page, generally there is a check to make sure that they can even view the page.

Conceptually, this all makes sense to me.  However, in practice, it has never been that easy.  Every single time I’ve wanted to code a website with some sort of user log in, I’ve had to spend several days researching tutorials on YouTube, and usually everyone has different ways to go about it.  Overall, another concern to me, was the privacy and safety of using cookies in general, which put me down a several-day long rabbit hole of how to even program user login, authentication, and authorization.

My initial plan with our capstone project was to create a user login and an authentication API using Nodejs that would send a cookie back to the front end. I had researched this for days as previously stated, and was given a lot of conflicting information on cookies in general. So, after this I had also integrated JSON Web tokens in to my cookie to ensure that it was safe. My biggest fear was what to do with the token on the front end of the website after it was created, and decided to back-burner the concept until more functionality was complete in both front and back ends.

Ironically enough, the answer to all of our problems came to us in the form of the front end library we were using. When one of the front end engineers in my group showed me the starter website that is created using Remix had successfully logging in a user, and displaying their name. I realized that there had to be some way this information was getting there. Luckily for us, as it turns out, the starting website when you create a new Remix application already has code to handle showing logged in users certain pages, and the login process using their Primsa database.

After reading through, and playing with the code of the Remix front end for a few hours, I came to learn that the user id is retrieved from the database, and that is stored in the cookie. This is something that could easily be replaced with an API call to get the user’s id from the API. Just like that, my long research process of trying to understand cookies ended by working smarter and not harder.


Woes of Job-Hunting

It is no secret that job-hunting for most people is not fun. In fact, if you like job-hunting or overall enjoy the process, consider yourself a unicorn.

Last year during October, I pushed myself hard to find an internship, I spend most of my free time outside of school hunting. It was a process that was long, rough, and it made my imposter syndrome far worse. At the end of this long process, I finally got an internship with a company asked me about my personal projects which related to the job far more than any coding assessment and impressed my manager.

Excerpt of my compiled job-hunting Google Sheet.

Now that October is here again, and my graduation quickly on the horizon, I am in full swing of job-hunting once again. In an effort to really see how much work I am putting in to this process while in school, I decided that I was going to track the jobs that I applied to in a Google Sheet. I am also someone who tends to like numbers, given that my first degree was in Mathematics with a focus on statistics. I was greatly interested in the numbers game I would be playing trying to find an entry level job during an economic downturn right before I graduate.

Current running total of my job applications, rejections, ghosts, initial phone screens, interviews, and offers.

Ironically, when my capstone group was given the list of potential projects we could do, the fact that two of us were job hunting was a huge reason why we wanted to do the job tracker project. Not only this, but the two of us were also compiling similar lists of what jobs we had applied for. We realized that we knew really well what the end user’s needs would be for a website like this. Not only this, but we had a lot of data we could use for the development database, since we both had very similar tables. As a group we also understood that job hunting will never be fun, but making it easier to track what jobs you have applied to, and have numbers on it, does make life a lot easier.

While job-hunting is a long and difficult process, luckily as a group we were given the information and drive to make something of it. Hopefully the job-hunt gets better in the future, but while that happens we get to make a really cool project that will help us in the future.


A Retrospective of my Software Engineering Journey

Hello World everyone! My name is Alyssa Comstock, and I’m happy to announce this is my final term before I graduate here at Oregon State University! To say that my journey though my computer science degree has been rough is an understatement. Because of this I am proud to have gotten this far.

I am a post-baccalaureate student. My previous degree was in Mathematics, which I received in August 2019 from Portland State University. Even before this, I had tried to pursue my computer science degree at Portland State University, however as a freshman I made a lot of mistakes, and this resulted in me changing my degree path. At the time I thought that was what I wanted, however as time went on, and when I finally graduated, I realized that my interests still gravitate towards programming, software engineering, and website development related topics. When the pandemic hit a few months after graduating the first time, going back to school for something I really enjoyed was an easy choice. Oregon State University offering remote classes with a bonus.

Growing up, my mother was also a computer scientist, and hearing her talk about computers and software always interested me. This was the first thing that planted the seed in my mind, that this was something that I enjoyed. Not only this, but I grew up in a time where social media was not as much of a thing, but virtual pet websites like Neopets were greatly popular with people my age. On Neopets, kids were often given their first chance to program very simple HTML / CSS websites, which I thought was the coolest thing EVER at 10 years old. I wanted to make every website that I touched glittery! The combination of being surrounded by tech-y people, and being given access to the tools to learn very simple website development from a young age was what really got me interested in these topics.

Now that I am almost at the end of my journey getting my computer science degree, I like to think about how proud past me would be of how far I’ve come from my time at Portland State University. I think 10 year old me who got their start coding small HTML / CSS websites would think it is super cool that I can make every website glittery if I wanted to :).